Уязвимость в NEGOEX SPNEGO стала RCE, проверьте наличие сентябрьского патча

Уязвимость в NEGOEX SPNEGO стала RCE, проверьте наличие сентябрьского патча

Уязвимость в NEGOEX SPNEGO стала RCE, проверьте наличие сентябрьского патча

Два дня назад Microsoft обновила бюллетень по закрытой в сентябре уязвимости в NEGOEX (расширении SPNEGO), повысив опасность угрозы до критического уровня. Как оказалось, эксплойт позволяет не только добраться до конфиденциальной информации, но также удаленно выполнить произвольный код.

Проблему усугубляет тот факт, что CVE-2022-37958 способна обеспечить большую площадь атаки для самоходных сетевых червей. Механизм безопасности SPNEGO используют многие протоколы приложений Windows: RDP, SMB, SMTP, HTTP; и для всех этих служб он включен по умолчанию, начиная с Windows 7.

Последствия могут быть разрушительными — достаточно вспомнить эпидемию WannaCry или Petya, а ведь эти шифровальщики с функциями червя использовали лишь один уязвимый протокол Windows — SMB (CVE-2017-0144, она же EternalBlue).

Возможность удаленного исполнения кода с помощью CVE-2022-37958 обнаружила эксперт IBM X-Force Валентина Пальмьотти (Valentina Palmiotti). Согласно описанию в блоге X-Force, эксплойт можно провести, получив доступ к NEGOEX через любую службу, использующую этот механизм расширенного согласования протокола аутентификации.

Взаимодействия с пользователем атака в данном случае не требует, однако добиться успеха с первой попытки вряд ли удастся. В связи с этим степень опасности RCE-проблемы Microsoft оценила в 8,1 балла CVSS — как высокую. Тем не менее всем обновлениям с патчем для Windows присвоен статус «критическое».

Подробности уязвимости до сих пор не опубликованы: пользователям дали дополнительное время на латание дыр. Всем, кто это еще не сделал, настоятельно советуют установить обновления безопасности от 13 сентября. Другие полезные рекомендации:

  • проверить интернет-доступ к затронутым сервисам (SMB, RDP);
  • непрерывно мониторить внешний периметр, особенно веб-серверы IIS с включенной аутентификацией Windows;
  • сократить число провайдеров аутентификации, оставив лишь Kerberos или Net-NTLM; удалить дефолтного провайдера Negotiate.

Проводник Windows падал не из-за Microsoft, виноват оказался деинсталлятор

Инженер Microsoft Рэймонд Чен рассказал любопытную историю отладки загадочных падений Проводника. Сначала всё выглядело так, будто в Windows внезапно появился неприятный баг. Но виновником оказалась вовсе не Microsoft, а сторонний деинсталлятор.

Проблема проявилась как резкий всплеск сбоев Проводника. Инженеры начали изучать дампы и заметили странную деталь: падала 32-битная версия программы, запущенная на 64-битных системах Windows.

Такая версия Проводника всё ещё есть в Windows ради совместимости со старыми приложениями. Обычно современные системы почти не используют этот путь. Но в данном случае сторонний деинсталлятор каким-то образом заставлял систему обращаться именно к этому устаревшему компоненту.

Дальше выяснилось, что деинсталлятор некорректно работал с системными API: использовал неправильное соглашение о вызовах функций и неверно обрабатывал параметры стека. Из-за этого при каждой неудачной операции данные из стека удалялись неправильно.

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

Со стороны всё выглядело как типичная системная ошибка: софт снова и снова аварийно завершал работу, создавая ощущение, что проблема в самой Windows. На деле операционная система лишь показывала последствия ошибки в стороннем ПО.

Чен напомнил важную вещь: в экосистеме Windows с миллиардами устройств и огромным количеством приложений далеко не каждый сбой компонента Microsoft означает баг в Windows. Сторонние программы тоже могут ломать системные процессы, особенно если неправильно используют низкоуровневые API.

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