PHP оказался подвержен критически опасной уязвимости

PHP оказался подвержен критически опасной уязвимости

В популярном скриптиновгом языке PHP и серверном интерпретаторе для него была обнаружена открытая уязвимость, которая ставит под удар огромное количество сайтов. Хуже того, уязвимость уже используется, а автоматизированные программы пытаются выявить серверы, которые можно атаковать и захватить.

Атака, связанная с выполнением кода, угрожает лишь тем PHP-сайтам, которые используют режим работы CGI (Common Gateway Interface), говорит Дариан Энтони Патрик, консультант по безопасности компании Criticode. Те же сайты, что используют PHP в режиме FastCGI не затронуты проблемой. Сейчас практически невозможно сказать, сколько именно сайтов оказались под ударом, так как они для проведения успешной атаки должны обладать еще несколькими критериями, в частности, иметь открытыми некоторые порты.

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

В компании Trustwave говорят, что у них специально установлены несколько серверов стандартной конфигурации, выполняющих роль приманок для потенциальных атакующих и некоторые из них уже были атакованы через новую уязвимость в PHP. Некоторые серверы просто обработали хакерские запросы на проверку софта на уязвимость, другие перенесли реальные попытки взлома. В целом, по данным этой компании можно говорить, что через автоматизированные средства взламывается примерно десяток сайтов ежечасно, передает cybersecurity.

После взлома на многих из них размещаются ссылки на вредоносное ПО, а также ссылки на хакерские ресурсы в США и Китае для проведения Drive-By атак. Также известно, что в популярном наборе Metasploit для сканирования на уязвимости новая атака уже описана, что позволяет атаковать целевой сервер буквально одним нажатием кнопки.

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

Многие специалисты говорят, что количество PHP-серверов, работающих в режиме CGI сравнительно мало, однако с учетом популярности этого языка, а также критической опасности бага, все же рекомендуется как можно скорее установить исправление.

Почему не стоит входить с помощью Google в важные аккаунты

Кнопка «Войти с аккаунтом Google» долго казалась удобным решением, ибо не нужно придумывать новый пароль, заполнять профиль и помнить ещё одни учётные данные. Но у такого удобства есть обратная сторона. Главный риск — зависимость от одного аккаунта.

Если пользователь потеряет доступ к Google из-за взлома, блокировки, фишинга или другой проблемы, под ударом окажутся не только Gmail и Диск, но и все сторонние сервисы, куда он входил через Google.

Это может быть что угодно: рабочие инструменты, доставка еды, такси, умный дом, сервисы ИИ, приложения для путешествий или финансов.

Есть и вопрос безопасности. Современные фишинговые атаки умеют подделывать страницу входа Google и перехватывать не только пароль, но и сессионные токены.

В таком случае злоумышленник может получить доступ к аккаунту даже при включённой двухфакторной аутентификации. Чем чаще пользователь входит в разные сервисы через всплывающие окна Google, тем выше риск попасть на такую подделку.

Ещё один минус — недостаток конфиденциальности. Когда разные сервисы привязаны к одному Google-аккаунту, компания получает более цельную картину цифровой активности пользователя: какие приложения он использует, как часто и в каких сценариях. Даже если данные обрабатываются в агрегированном виде, это всё равно расширяет цифровой след.

Более безопасная альтернатива — создавать отдельные учётные записи для важных сервисов и хранить пароли в менеджере паролей. Это менее удобно на старте, зато снижает риск единой точки отказа. Если один аккаунт будет скомпрометирован или заблокирован, остальные не посыплются вслед за ним.

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

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