В установщике Notepad++ нашли уязвимость с повышением привилегий

В установщике Notepad++ нашли уязвимость с повышением привилегий

В установщике Notepad++ нашли уязвимость с повышением привилегий

Если вы недавно ставили Notepad++ версии 8.8.1, есть плохая новость: в инсталляторе обнаружили серьёзную уязвимость, через которую обычный пользователь мог получить права администратора уровня SYSTEM. Всё из-за классической ошибки с «поиском исполняемых файлов не там, где надо».

Суть проблемы — в том, как установщик искал системные утилиты вроде regsvr32. Вместо того чтобы обращаться к ним по абсолютному пути (например, C:\Windows\System32\regsvr32.exe), инсталлятор просто писал regsvr32.

А это значит, что Windows сначала смотрит в ту папку, откуда запускается установщик. Подсовываем туда вредоносную версию — и готово: зловред запускается с правами SYSTEM без всяких предупреждений.

Что особенно тревожно — взаимодействие с пользователем требуется минимальное. Всё, что нужно злоумышленнику, — убедить жертву скачать и положить два файла в одну папку: сам инсталлятор и поддельный regsvr32.exe. Например, в «Загрузки». После запуска установщика эксплуатация происходит автоматически.

 

В Notepad++ быстро отреагировали: уязвимость закрыта в версии 8.8.2. Разработчики обновили скрипт установки и теперь явно указывают путь к regsvr32 — как и советует Microsoft. Так что если у вас до сих пор стоит версия 8.8.1 — самое время обновиться.

Эксплойт уже подтверждён — исследователи выложили PoC и видео с демонстрацией успешной атаки. Уязвимость напоминает другие аналогичные случаи, включая недавние баги в Dell SupportAssist и CVE из 2023-2024 годов.

Что делать:

  • Обновитесь до Notepad++ 8.8.2.
  • Не запускайте установщики из папок с подозрительными файлами.
  • Используйте только оригинальные дистрибутивы.

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

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

Новая атака на кеш Nginx позволяет красть данные и ломать сайты

Исследователь YesWeHack Алекс Брумен описал вектор кибератаки Cache Key Injection. В случае её эксплуатации последствия для потенциальной жертвы опасные: обход контроля доступа, раскрытие закрытых страниц, отказ в обслуживании и при определённых условиях.

Как объясняет исследователь YesWeHack, проблема возникает не в Nginx по умолчанию, а в конфигурациях, где администраторы просто склеивают несколько значений переменной длины без разделителей. Например:

$scheme$host$request_uri$http_accept

Разных запроса два, а итоговая строка может получиться одна. Так, запрос к /h с заголовком Accept: ome*/* создаёт тот же ключ, что и обычное обращение к /home с Accept: */*.

Если атакующий успеет первым положить в кеш ответ 404, пользователи вместо главной страницы будут получать ошибку до очистки записи. Получается CPDoS — отказ в обслуживании с доставкой прямо из кеша.

 

Ещё веселее становится с закрытыми разделами. В лабораторном примере страница /admin была доступна только с localhost, но злоумышленник мог обратиться к /ad и перенести оставшуюся часть имени в соседний компонент ключа. Nginx видел разрешённый путь, однако доставал из кеша содержимое админ-панели.

При совпадении нескольких условий техника позволяет столкнуть HTTP- и HTTPS-запросы и записать в кеш страницу со ссылкой на атакующий JavaScript, превратив ошибку конфигурации в stored XSS. Даже Cloudflare не всегда спасёт: заголовок Authorization может провести запрос мимо его кеша прямо к уязвимому кешу Nginx.

 

Защита выглядит до смешного просто: не склеивать значения вслепую. Между элементами ключа нужны разделители или структурное кодирование, например:

$scheme|$host|$request_uri|$http_accept

Также следует проверять Host, перенаправлять HTTP на HTTPS и не кешировать аутентифицированные запросы.

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