Инцидент PHP2Shell показал, как хостинг-провайдеры справляются с кризисными ситуациями в сфере безопасности
Когда появились первые сообщения о критических уязвимостях в PHP, Джон Блэкборн находился в Нидерландах на конференции Open Source CMS 26, организованной компанией Boye & Co. По стечению обстоятельств он оказался за одним столом с разработчиками и специалистами по безопасности из проектов Drupal, TYPO3 и Tumblr — они «обменивались информацией, пытаясь понять, что происходит».
Нечто подобное происходило и во всей индустрии веб-хостинга.
20 октября команда проекта PHP объявила о скором выпуске исправлений для двух уязвимостей — это произошло после того, как подробности о них просочились в сеть. Из-за утечки разработчикам пришлось в спешном порядке готовить патчи, чтобы опередить злоумышленников, которые могли воспользоваться уязвимостями. Позже эти уязвимости получили название PHP2Shell.
Закрытый Slack-канал команды безопасности WordPress, предназначенный для координации действий с хостинг-провайдерами и другими заинтересованными сторонами, быстро превратился в импровизированный штаб по реагированию на инциденты. Джон Блэкборн, представитель команды и директор по безопасности WordPress в компании Human Made, рассказал, что следующие 24 часа участники провели в постоянном обмене ссылками и проверке поступающих данных. Они пытались оценить масштаб угрозы и найти способы ее нейтрализации, не имея при этом четкого представления о том, с чем именно имеют дело.
«Некоторые хостинг-провайдеры начали делиться ссылками, отмечая, что пытаются разобраться в ситуации. Кто-то получил доступ к подробностям до официального раскрытия (на условиях неразглашения), но большинство — нет», — сообщил он.
Команда PHP выпустила исправления в среду, 21 октября, в 14:00 по UTC — на день раньше запланированного срока. Некоторые компании работали с командой безопасности PHP в режиме конфиденциальности, однако большинство хостинг-провайдеров, с которыми пообщались наши представители, узнали о проблеме одновременно со всеми остальными.
В ожидании того, пока небольшая группа ответственных за сопровождение пакетов подготовит обновленные сборки, хостинг-провайдеры задействовали правила файрволов. Большинству удалось внедрить исправления в течение нескольких часов, тогда как у других на это ушли дни.
Спустя три недели компании, занимающиеся вопросами кибербезопасности, так и не подтвердили ни одного случая взлома сайта на WordPress через уязвимость PHP2Shell. Это заставило некоторых задаться вопросом: была ли поднятая тревога оправданной? Однако этот инцидент также позволил взглянуть на то, как хостинг-провайдеры в экосистеме WordPress справляются с кризисными ситуациями: кого они предупреждают заранее, на какие компании все полагаются для минимизации рисков и как хостинг-провайдеры выстраивают коммуникацию со своими клиентами. То, как именно они отреагировали — и насколько оперативно, — в итоге само по себе превратилось в маркетинговый аргумент.
Содержание
- Кто что знал
- Сначала — меры защиты, потом — исправления
- В ожидании мейнтейнеров
- Что сообщали клиентам
- Подтвержденных случаев взлома нет
- Использование в качестве маркетингового аргумента
- Что дальше
Кто что знал
Проект WordPress, включая его команду по безопасности, не был заранее уведомлен о готовящихся исправлениях для PHP.
«WordPress не получил никакого предварительного уведомления об этом анонсе, что весьма прискорбно. На мой взгляд, такое уведомление должно было быть», — отметил Блэкборн.
Хостинг-провайдеры также оказались застигнуты врасплох.
«Мы узнали об этом одновременно с остальным интернетом — в тот момент, когда информация просочилась до официального снятия эмбарго», — рассказал Слейд Козарт, вице-президент по взаимодействию с клиентами в WP Engine.
Компания Cloudflare, напротив, знала о готовящихся исправлениях, поскольку сотрудничала с командой безопасности PHP еще до их выпуска. В своем блоге компания сообщила, что «участвовала в скоординированных действиях по внедрению защитных мер для обеспечения безопасности интернета, работая, в частности, с PHP Foundation, OpenAI и Wiz». В Cloudflare также добавили, что с начала октября занимались разработкой правил для файрвола.
В Automattic также заявили о тесном сотрудничестве с командой безопасности PHP. В публикации от 21 октября руководитель отдела безопасности Руди Фейл написал, что сайты на платформах WordPress.com, WordPress VIP, WP Cloud, Pressable и Tumblr «уже защищены». Он также добавил, что Automattic входит в число компаний, которые компания Wiz поблагодарила за помощь в подготовке рекомендаций и защитных мер.
В чем именно заключалась эта работа — остается неясным. Ни в публикации Automattic, ни на странице статуса сервисов Pressable не упоминается конкретная версия PHP с внесенными исправлениями. В обоих случаях сайты клиентов описываются как «защищенные», а не как «обновленные». Мы попросили Фейла уточнить, что это означает на практике, но он отказался вдаваться в подробности.
«Безопасность — деликатная сфера, поэтому я предпочел бы не раскрывать детали наших внутренних процессов или механизмов координации с другими организациями. Думаю, в моем блоге освещены все ключевые моменты, включая сотрудничество, благодаря которому это стало возможным», — сообщил он.
Клиенты не знали, кто из хостинг-провайдеров был посвящен в планы, а кто — нет. Лорен Кокс, старший директор по коммуникациям в WP Engine, отметила, что многие клиенты полагали, будто их хостинг-провайдеры были предупреждены заранее, и были разочарованы, когда выяснилось, что те не предприняли никаких действий раньше. «Мне кажется, люди не поняли, что было нарушено эмбарго. Из-за этого возникло сильное недовольство: «Почему вы не выпустили патч? Почему не сказали об этом нам лично?»» — отметила она.
Сначала — меры защиты, потом — исправления
Для многих компаний Cloudflare стал первой линией обороны. Согласно публикации самой компании, защита с помощью WAF была активирована для пользователей как бесплатных, так и платных тарифов 21 октября в 03:02 по UTC. Это произошло почти за 11 часов до того, как разработчики PHP выпустили официальные исправления. В Cloudflare также сообщили, что внедрили ряд защитных мер еще до официального релиза, когда подробности об уязвимостях уже начали распространяться.
В публикации от 29 октября компания Kinsta отметила, что правила Cloudflare охватили все сайты на ее платформе. Клиенты Rocket.net оказались защищены благодаря корпоративной версии WAF от Cloudflare. Компания WP Engine, использующая решения Cloudflare и Fastly, активировала правила файрвола вскоре после полуночи 21 октября (по центральноамериканскому времени), о чем сообщил клиентам представитель компании Козарт.
Арнас Донаускас, менеджер по продуктам веб-хостинга в Hostinger, рассказал, что их компания также внедрила правила файрвола еще до выхода исправлений для PHP. После этого специалисты по безопасности протестировали имеющиеся эксплойты на собственных ресурсах компании — файрвол успешно их заблокировал. Кроме того, в Hostinger отключили функцию PHP для отслеживания прогресса загрузки сессий — она редко используется на WordPress-сайтах, но в данном случае решили, что «береженого бог бережет».
По словам Блэкборна, участники закрытого Slack-канала, представляющие различные хостинг-провайдеры, начали фиксировать попытки использования эксплойтов, которые блокировались их файрволами, примерно в 06:00 UTC 21 октября. К тому моменту у большинства из них уже действовали те или иные меры защиты.
Именно тогда клиенты начали проявлять беспокойство. Инцидент с PHP2Shell получил широкую огласку — случай, довольно редкий для сферы веб-безопасности: о нем рассказывали в новостях на коммерческих телеканалах, поступали сообщения об отключении правительственных сайтов в Европе, а премьер-министр Японии даже упомянул об этом в социальных сетях.
Как сообщает Kinsta, клиенты самостоятельно отключили 3 000 сайтов, несмотря на рекомендации инженеров компании этого не делать. В WP Engine, по словам Козарта, владельцы критически важных ресурсов интересовались, стоит ли им также приостановить работу своих сайтов. Однако представители компании разъяснили им суть принятых защитных мер, а тем, кто хотел получить дополнительную подстраховку, помогли, например, установить парольную защиту на сайты.
В ожидании мейнтейнеров
После того как для PHP вышли исправления, хостинг-провайдеры столкнулись с типичной для проектов с открытым исходным кодом проблемой — нехваткой мейнтейнеров.
Большинство хостинг-провайдеров не компилируют PHP самостоятельно. Они полагаются на пакеты, подготовленные разработчиками операционных систем, поставщиками панелей управления (например, cPanel) или независимыми мейнтейнерами. Пока такие пакеты не были готовы, многие провайдеры не могли установить обновления на свои серверы.
«Выпуск всех этих пакетов зависит от очень, очень небольшого числа людей», — отметил Блэкборн.
Скорость внедрения исправлений зависела от того, откуда хостинг-провайдеры получали пакеты PHP. Ондржей Суры — волонтер (ныне широко известный в сообществе), отвечающий за поддержку пакетов PHP для Debian и Ubuntu, — опубликовал исправленные сборки в тот же день. В то же время CloudLinux и cPanel на момент выхода обновлений всё еще занимались подготовкой своих пакетов. К 23 октября компания CloudLinux уже предоставила исправленные сборки для всех версий PHP в своих стабильных репозиториях.
Платформа Altis от компании Human Made столкнулась с иным препятствием: команде пришлось три часа ждать появления официального Docker-образа PHP, прежде чем они смогли применить исправления.
«Нам пришлось ждать, пока человек на западном побережье США проснется и смерджит пул-реквест», — рассказал Блэкборн.
Согласно данным из репозиториев Docker на GitHub, для обновления потребовалось два пул-реквеста. Первый, содержащий обновления файлов сборки образа PHP, был создан 21 октября в 13:44 UTC. Второй, направленный на сборку и публикацию образов, — в 14:29 UTC. Тианон Грави, сопровождающий Docker из Лас-Вегаса, одобрил и объединил изменения в 8:16 утра по местному времени (15:16 UTC).
Пока тянулось ожидание, ветка обсуждения наполнилась сотнями мемов и острот. Каждый новый комментарий запускал автоматизированные рабочие процессы, что еще больше замедляло работу. В конечном итоге мейнтейнеры заблокировали обсуждение, чтобы иметь возможность спокойно завершить задачу.
Теперь в Altis планируют создавать собственные образы PHP; по оценкам Блэкборна, у команды это будет занимать около 20 минут. Компания GoDaddy также была вынуждена дожидаться получения пакетов от своего поставщика, временно применяя меры по защите серверов. К 19:30 UTC 21 октября — примерно через пять с половиной часов после выхода исправлений от разработчиков PHP — компания завершила обновление серверов, используемых для услуги «управляемый хостинг для WordPress» («Managed Hosting for WordPress»). С серверами для обычного веб-хостинга, где применяются специализированные PHP-пакеты от CloudLinux, процесс занял больше времени: их обновление было завершено лишь к 13:30 UTC следующего дня, спустя почти 24 часа после выпуска исправлений.
В целом по отрасли сроки внедрения обновлений существенно различались. Компания WP Engine завершила процесс 22 октября в 01:19 UTC; Hostinger — 22 октября в 06:44 UTC (для всех тарифных планов, кроме VPS); а Kinsta — 22 октября в 08:26 UTC.
На странице статуса сервисов Bluehost 23 октября всё ещё сообщалось о ходе работ, однако последующих обновлений о завершении процесса опубликовано не было. Компания Rocket.net отметила инцидент как решённый, не подтвердив при этом, что внедрение обновлений полностью завершено.
У Nexcess процесс внедрения занял больше всего времени — по крайней мере, из тех случаев, о которых стало известно публично. 22 октября на странице статуса компании появился список из десятков исправленных сборок PHP, включая версии вплоть до 5.2. Лишь 29 октября в 15:41 по восточному времени (ET) — спустя восемь дней после выхода исправлений PHP — в Nexcess сообщили, что обновления «были развёрнуты на всей инфраструктуре хостинга».
Что сообщали клиентам
Для клиентов ситуация с PHP2Shell оставалась, по сути, «черным ящиком». Они не видели, какие меры принимают хостинг-провайдеры, и зачастую даже не знали, предпринимаются ли вообще какие-либо действия.
Незадолго до выпуска патчей разработчик Джон Браун задал вопрос в социальной сети X: получал ли кто-нибудь уведомления от крупных хостинг-провайдеров? Упомянув такие компании, как WP Engine, Automattic, GoDaddy и Liquid Web, он охарактеризовал ситуацию как «полное молчание».
Ответы пользователей разнились. Некоторые клиенты сообщили, что не получили никаких известий от таких провайдеров, как SiteGround, Kinsta, Liquid Web и Pantheon. Другие, напротив, похвалили Cloudways, Hostinger, WordPress VIP и ряд более мелких компаний за рассылку электронных писем, размещение уведомлений в панелях управления и обновление страниц с информацией о состоянии сервисов.
Сведения также были противоречивыми. Так, одни клиенты SiteGround заявили, что не получали никаких сообщений, тогда как другие сослались на публикацию в блоге компании. Hostinger заслужил одобрение за своевременные обновления, однако нашелся как минимум один клиент, который не получил от компании никакой информации.
Позднее Козарт в письме, которое WP Engine направила своим клиентам, признал, что не все получали регулярные и актуальные обновления.
В беседе он отметил, что 21 октября объем обращений в службу поддержки через чат многократно превысил обычные показатели для среды: клиенты пытались выяснить, что происходит и находятся ли их сайты в безопасности. По словам Кокса, страница с информацией о состоянии сервисов WP Engine служила «надежным источником» на фоне потока противоречивых данных. Козарт добавил, что компания не считала возможным заверять клиентов в полной защищенности до тех пор, пока не будут установлены все необходимые патчи.
В Hostinger выбрали иной подход: компания информировала клиентов по мере внедрения защитных мер — сначала были применены правила файрвола, затем отключена функция отслеживания прогресса загрузки сессий в PHP, а позже, по мере готовности, установлены патчи на всех серверах. Донаускас рассказал, что в процессе реагирования участвовало несколько подразделений — «от принятия мер по защите до взаимодействия с клиентами».
«Самое важное — как быстро вы осознаете необходимость принятия мер и как оперативно информируете об этом своих клиентов», — подчеркнул он.
Подтвержденных случаев взлома нет
Генеральный директор Wordfence Марк Маундер стал одним из наиболее активных критиков того, как преподносится информация о PHP2Shell. 23 октября он написал в социальной сети X, что среди 5 миллионов PHP-сайтов, защищаемых продуктами Wordfence, не было зафиксировано «ни одного взлома, связанного с PHP2Shell. Вообще ни одного».
Маундер отметил, что, хотя тема получила широкое освещение, практически никто не обратил внимания на отсутствие подтвержденных фактов компрометации систем. По его словам, компаниям в сфере кибербезопасности следует соизмерять свои предупреждения с реальной сложностью эксплуатации уязвимостей — в противном случае они рискуют вызвать у пользователей «усталость от оповещений» и утратить доверие.
Тем не менее, подозрительная активность наблюдалась. В обновлении от 28 октября специалисты Wordfence сообщили, что специальное правило мониторинга зафиксировало около 77 600 запросов, связанных с PHP2Shell, которые поступили с более чем 2 000 IP-адресов в период с 23 по 27 октября. К тому моменту команды Wordfence, занимающиеся очисткой сайтов и реагированием на инциденты, не сталкивались ни с одним случаем взлома WordPress, который можно было бы связать с этими уязвимостями.
Аналогичные данные привел генеральный директор Patchstack Оливер Силд. 23 октября, отвечая Маундеру, он отметил, что компания фиксирует в основном «зондирование» и «черновые варианты эксплойтов», однако убедительных доказательств успешных атак нет. Он также добавил, что многие из тех, кто ранее сообщал об активных попытках эксплуатации, использовали защиту Cloudflare.
Впрочем, успешные атаки все же имели место — правда, не на сайты на базе WordPress. 24 октября исследователь Адель Карими зафиксировал 35 случаев успешного выполнения команд через шелл на трех PHP-ханипотах — специально созданных ловушках, работающих на базе PHP 8.4.26 и веб-сервера Apache. Позднее стало известно, что злоумышленники использовали эксплойт PHP2Shell в сочетании с отдельной уязвимостью в ядре Linux, чтобы получить root-доступ к 25 серверам под управлением PAN-OS (включая 24 файрвола и один внутренний сервер управления). Подразделение Unit 42 компании Palo Alto Networks провело независимую проверку инструментов злоумышленников и подтвердило полученные результаты.
Брент Стэкхаус, вице-президент по производственным операциям и директор по информационной безопасности (CISO) в компании WP Engine, не согласился с тем, что произошедшее можно назвать «ложной тревогой». «Нехватка информации мешает как атакующим, так и защитникам. И хотя массовых атак, по-видимому, не произошло, в конечном счете это даже хорошо для всей экосистемы: команды смогли провести своего рода учения в «боевых» условиях и проверить все этапы реагирования на инциденты», — отметил он.
«Рассматривать эту ситуацию как «ложное срабатывание» — не лучший подход для владельцев сайтов или хостинг-провайдеров, чьи ресурсы могли быть скомпрометированы. Нет исчерпывающих данных, подтверждающих, что успешных атак не было вовсе; более того, поступающая на этой неделе информация указывает на то, что провести успешную атаку можно было буквально за считаные часы», — добавил он.
По словам Блэкборна, хостинг-провайдеры крайне неохотно делятся подобными данными — даже с командой по безопасности.
«Мы уже спрашивали хостинги, были ли у них взломанные сайты, но они просто молчат. Они категорически не хотят раскрывать информацию о взломах, опасаясь, что она станет достоянием общественности — и тогда кто-нибудь заявит: «Ого, у GoDaddy взломали 10 000 сайтов!». Поэтому получить от них такие сведения практически невозможно», — пояснил он.
Использование в качестве маркетингового аргумента
Тем временем некоторые компании превратили скорость своей реакции в маркетинговый аргумент.
Дженна Уэстбрук, курирующая стратегию развития веб-сайтов для государственного сектора в WordPress VIP, на прошлой неделе опубликовала в LinkedIn пост, в котором сравнила, как долго сайты клиентов оставались «в зоне риска» на различных хостинговых платформах.
Согласно ее инфографике, для WordPress.com, WordPress VIP и Pressable этот показатель составил ноль часов: компания Automattic заявила о своей готовности еще за семь часов до того, как разработчики PHP выпустили исправления. Для Pantheon, WP Engine, Acquia и Kinsta время ожидания варьировалось от 10 до 18,5 часов — исходя из того, когда именно эти компании применили патчи. В инфографике также упоминались промежуточные меры защиты, такие как сетевая фильтрация у Pantheon и правила файрвола Cloudflare, используемые Kinsta.
Пост завершался предупреждением о «цунами» угроз безопасности, которое надвигается на веб-сайты, и призывом «сесть в спасательную шлюпку Automattic». Уэстбрук предложила бесплатный перенос сайтов на WordPress до конца года, отметив, что клиентам стоит выбрать компанию, для которой безопасность является «главным приоритетом».
Соучредитель и старший вице-президент по маркетингу компании Pantheon Джош Кениг (чья компания фигурировала в сравнении) на этой неделе ответил публикацией в LinkedIn. Он указал, что в сравнении смешаны понятия «защита на уровне файрвола или периметра сети» (которая была у большинства крупных провайдеров) и «непосредственное обновление PHP».
Кениг подчеркнул, что большинство крупных хостинг-провайдеров использовали средства защиты на сетевом уровне, пока ожидали выхода исправлений для PHP; компания Automattic, по сути, делала то же самое с помощью собственных инструментов. Он добавил, что команда безопасности PHP еще до официального раскрытия уязвимости взаимодействовала со «многими специалистами» — в том числе с представителями Cloudflare — для подготовки защитных мер на уровне файрвола.
В комментариях к посту Уэстбрук защищала свою позицию, заявив, что лишь собрала общедоступную информацию. «Это простые выкладки. Я не занимаюсь PR или маркетингом», — написала она.
Издание поинтересовалось у Уэстбрук, когда именно на сайтах WordPress VIP было установлено обновление PHP (а не просто применены временные меры защиты), однако ответа не последовало. Мы также обратились к Фейлу с вопросом о сроках выпуска обновлений компанией Automattic, но он отказался от комментариев.
Что дальше
Инцидент с PHP2Shell не привел к той волне взломов сайтов на WordPress, которой многие опасались. Однако он обнажил проблемы, связанные с зависимостями и недостатками в коммуникации, которые неизбежно проявляются во время серьезных инцидентов в сфере безопасности: от сложностей, с которыми сталкиваются специалисты по защите, пытаясь разобраться в неполных данных, до вынужденного ожидания хостинг-провайдерами действий со стороны мейнтейнеров — при том, что сами клиенты зачастую остаются в неведении относительно того, что происходит «за кулисами».
Этот год стал рекордным для безопасности WordPress. В рамках программы на платформе HackerOne было получено больше сообщений об уязвимостях, чем за все предыдущие 12 лет вместе взятые. С середины июля для ядра WordPress вышло семь обновлений безопасности, а злоумышленники совершили взломы систем нескольких компаний-разработчиков плагинов, чтобы внедрить вредоносный код на сайты их клиентов.
Козарт не ожидает, что давление на хостинг-провайдеров в ближайшее время ослабнет, и отмечает, что подобные ситуации, скорее всего, повторятся.
«Злоумышленники не собираются сбавлять обороты — этого точно не произойдет, — говорит он. — Работа в качестве провайдера управляемого хостинга подразумевает, что мы будем сталкиваться с подобными вызовами, и наша задача — постоянно совершенствовать свои операционные процессы, чтобы справляться с ними всё лучше и лучше».
Источник: oddstyle.ru