В серверах OpenLiteSpeed найдены уязвимости, помогающие внедрить бэкдор

В серверах OpenLiteSpeed найдены уязвимости, помогающие внедрить бэкдор

В серверах OpenLiteSpeed найдены уязвимости, помогающие внедрить бэкдор

Специалисты Palo Alto Networks выявили три уязвимости в OpenLiteSpeed Web Server; как оказалось, в связке они позволяют скомпрометировать сервер и удаленно выполнить сторонний код с привилегиями root. Проблема актуальна также для LiteSpeed Web Server Enterprise; патчи уже доступны.

Серверный софт OpenLiteSpeed представляет собой opensource-версию продукта корпоративного класса, созданного LiteSpeed Technologies как альтернатива Apache. По данным Palo Alto, лицензионный LiteSpeed Web Server занимает шестое место по популярности среди веб-серверов; поиск по Shodan показал около 1,9 млн активных экземпляров LiteSpeed.

Две уязвимости, выявленные в OpenLiteSpeed (CVE-2022-0073 и CVE-2022-0074), эксперты оценили одинаково — в 8,8 балла CVSS. Третья была признана менее опасной (CVE-2022-0072, 5,8 балла).

Проблема CVE-2022-0073 классифицируется как возможность инъекции команд. Эксплойт требует доступа к админ-панели (учетные данные можно получить брутфорсом или с помощью социальной инженерии) и позволяет удаленно выполнить вредоносный код на сервере — даже из-под аккаунта nobody, по традиции создаваемого на Linux-машинах.

Использование CVE-2022-0074 поможет хакеру повысить привилегии в системе до уровня суперпользователя, а CVE-2022-0072 (обход каталога) обеспечит доступ к закрытым файлам. Таким образом, комбинация эксплойтов позволяет автору атаки скомпрометировать сервер, создать скрытый бэкдор и получить к нему доступ.

Наличие уязвимостей подтверждено для OpenLiteSpeed выпусков с 1.5.11 по 1.7.16 и LiteSpeed с 5.4.6 по 6.0.11. Патчи включены в состав сборок 1.7.16.1 и 6.0.12 соответственно.

Chrome прикрывает старую лазейку для слежки за пользователями Инкогнито

Google снова подкрутил Chrome так, чтобы сайтам было сложнее вычислять пользователей, сидящих в режиме инкогнито. Речь идёт о старом трюке, который годами использовали сайты и антифрод-системы. Через Storage API страницы могли запросить у Chrome информацию о доступном объёме хранилища.

В обычном режиме браузер показывал большой лимит, примерно соответствующий объёму диска устройства. А вот в режиме инкогнито он резко уменьшался, потому что данные там временные и сильно ограничены.

Этой разницы было достаточно, чтобы сервисы вроде detectIncognito почти безошибочно понимали: ага, пользователь открыл приватное окно.

 

Заодно сайты получали ещё один приятный бонус — возможность примерно оценить объём накопителя устройства. А это уже дополнительный отпечаток для слежки и фингерпринтинга.

Теперь Google решила прикрыть и эту лавочку. Chromium начал тестировать механизм predictable reported storage quota — предсказуемой квоты хранилища. Если коротко, Chrome перестаёт показывать сайтам реальные значения и вместо этого отдаёт одинаковый лимит независимо от режима работы браузера и железа пользователя.

Правда, в Google честно признают: полностью проблему это пока не убивает. Разработчики detectIncognito всё ещё могут определять приватные окна в стабильных версиях Chrome, используя комбинации разных сигналов. Но один из самых надёжных методов скоро отправится на пенсию.

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