мы обнаружили уязвимости в php скриптах на вашем аккаунте
Потенциальная уязвимость php-скриптов
Функции fopen, file, include и require могут открывать файлы с других сайтов по протоколам http и ftp. Эта возможность несёт в себе потенциальную уязвимость в php-скриптах, позволяющую использовать сайт как прокси.
Предупреждаю ничего нового в этом материале не будет. Несмотря на впечатляющие возможности для злоумышленника, данная уязвимость — просто комбинация общеизвестных свойств php.
В 2002 году параллельно несколькими группами, занимающимися поиском уязвимостей в ПО, была обнаружена серьёзная и мощная уязвимость в php.
В русскоязычном интернете эта уязвимость практически не была освещена. На русскоязычных сайтах по проблемам безопасности мне не удалось найти непосредственного сообщения об этой уязвимости.
Уязвимость: Url fopen wrapper
Для увеличения функциональности и упрощения кодирования, разработчики php сделали такую особенность в функциях fopen, file, include и прочих. Если имя файла начинается с http://, сервер выполнит HTTP-запрос, скачает страницу, и запишет в переменную как из обычного файла. Аналогично работают префиксы «ftp://», «php://» (последний предназначен для чтения и записи в stdin, stdout и stderr). Нужно это было для того, чтобы разработчики сайтов не мучались с библиотеками http-запросов и не писали их вручную. Данная опция отключается в настройках php, параметр allow_url_fopen.
CR/LF в HTTP-запросах
Комбинация символов carriage return и line feed в HTTP-запросе разделяет заголовки. Подробно об этом можно почитать в статье Антона Калмыкова « Генерация HTTP-запросов ». Эту комбинацию символов можно передать в GET-запросе в виде «%0D%0A».
Untrusted input
На многих сайтах страницы генерируются скриптом-шаблонизатором. В скрипт перенаправляются все запросы сайта. Из REQUEST_URI берётся имя файла, который надо открыть. Файл считывается, к нему добавляется шаблон с навигацией, шапкой и т.п., и результат выдаётся клиенту.
Нерадивый или неопытный программист запросто может написать открытие файла без проверки данных:
От запроса отбрасывается первый символ — слэш — и открывается файл. Злоумышленник легко может вписать в качестве пути к файлу на сервере строку http://example.com: http://n00b.programmer.com/http://example.com Другой вариант — все адреса на сайте имеют вид http://n00b.programmer.com/index.php?f=news В таком случае злоумышленник будет пробовать открыть адрес типа http://n00b.programmer.com/index.php?f=http://example.com Очень важно не доверять входящим данным и фильтровать при помощи регулярных выражений входящие запросы.
Эксплойт
Поскольку в приведённом примере адрес никак не проверяется, в запрос можно вставить строку с HTTP-запросом. Если злоумышленник откроет путь
то скрипт выполнит HTTP-запрос:
Последние три строки скрипт добавляет автоматически, но два rn перед ними означают конец запроса. Таким образом, незащищённый скрипт можно использовать как прокси-сервер. Зная несколько «дырявых» сайтов, злоумышленник может выстроить из них цепочку, чтобы его было сложнее найти.
Умное использование эксплойта
Если у провайдера, предоставляющего бесплатный демо-доступ, дырявый сайт, можно написать скрипт для домашнего сервера, который бы формировал запросы к такому прокси-серверу и экономил немного денег. Это дело, безусловно, подсудное и наказуемое, но по большому счёту баловство. Более прибыльное использование чужой машины как прокси — рассылка коммерческого спама. Пример из статьи, написанной Ульфом Харнхаммаром :
(должно быть одной строкой) модуль PHP соединится с сервером mail.example.com по 25 порту и отправит следующий запрос:
PHP и почтовый сервер будут ругаться, но письмо будет отправлено. Имея такую уязвимость в чьем-то сайте, можно искать закрытый почтовый релей, принимающий от эксплуатируемого веб-сервера почту. Этот релей не будет в чёрных списках провайдеров, и рассылка спама может получиться очень эффективной. На своём сайте я нашёл множество запросов с 25-м портом в пути. Причём до начала этого года таких запросов не было. Раньше о такой уязвимости знали единицы любопытных пользователей, и лишь в прошлом году дыра стала общеизвестной и поставлена на поток спаммерами.
Меры защиты от эксплойта
Вам, как разработчику или владельцу сайта, важно сделать всё возможное, чтобы через ваш сайт никто не смог разослать спам. Если это получится, разослан он будет с какого-нибудь гавайского диалапа, владельцы которого не понимают человеческого языка, а крайним могут сделать именно вас.
Проверка журнала запросов
Для начала полезно ознакомиться со списком уникальных адресов, запрашиваемых с сайта. Это поможет узнать, были ли случаи атак и использования дырки. Обычно спамеры сразу проверяют возможность соединения с нужным им почтовым релеем по 25 порту. Поэтому искать следует строки «:25» и «%3A25».
Настройка php
Изменение кода
Возможна такая сложная ситуация: вы клиент, а нерадивый админ хостинг-провайдера вписал все установки php в php_admin_value, и поменять их нельзя. Придётся модифицировать код скриптов. Самый простой способ — искать функции fopen, file и include, открывающие файлы из имён переменных. И вырезать функцией str_replace префиксы http:// и ftp://. Впрочем, иногда скрипту, всё-таки, необходимо открывать адреса, которые приходят от пользователя. Например, скрипт-порнолизатор, который вставляет в текст матерки или заменяет текст на ломаный русский язык («трасса для настайащих аццоф, фсем ффтыкать»). Наверное, больше всего от неряшливого программирования пострадали именно эти сайты. В данном случае вполне можно ограничиться вырезанием «rn» из полученной строки. В таком случае злоумышленник не сможет добавить свой собственный заголовок к запросу, который отправляете вы.
Прекращение работы при оффенсивном запросе
При этом предполагается, что на сайте не будут отправляться методом GET формы с многострочным пользовательским вводом. Иначе они будут остановлены этим правилом.
Если вы при помощи mod_rewrite поддерживаете адресацию, удобную для чтения, то скорее всего, двоеточие и CRLF не используются. Поэтому другие строки RewriteRule не будут подходить под сканирующий запрос, и строку, прекращающую обработку запроса, лучше поместить в конце списка правил. Тогда обычные запросы будут переписываться и перенаправляться до этой строки (используйте флаг [L]), что уменьшит время их обаботки. В зависимости от разных условий оно может варьироваться.
5 главных уязвимостей PHP безопасности
Учитывая тот факт, что взлом некоторых сайтов может принести немалую выгоду, а для того, чтобы его осуществить, преступнику даже не нужно выходить из дома, можно сделать вывод, что взлом сайта – очень заманчивое занятие для преступника. В дополнение к этому, злоумышленники в интернете очень редко несут наказания за свои деяния.
Но для того, чтобы взломать ресурс, хакер должен найти уязвимости в его работе. Пяти главным уязвимостям php и будет посвящена данная статья.
SQL Injection
Очень популярным методом взлома сайта среди хакеров является вставка SQL фрагмента вместо URL. В таком случае злоумышленник получает доступ к именам ваших таблиц. Чтобы избежать такого взлома, следует очень внимательно отслеживать все данные, которые присылают вам пользователи. Для борьбы с такими взломами обычно применяют PDO.
Cross site scripting
Так называемый XSS тоже является очень популярным способом взлома. Злоумышленники внедряют опасный код, обычно это JavaScript, в код вашего скрипта PHP. Это становится возможным в случае, когда отображены входные данные пользователей, которые были посланы вам из различных форм, блогов, форумов, чатов и т.д. Если в этих данных содержится вредоносный код, то ваш сайт может быть взломан.
Откровения в исходном коде
Еще одна уязвимость сайтов php – когда злоумышленники, в случае сбоя настроек Apache, могут видеть содержимое и названия ваших файлов. В нормальной ситуации PHP выполняется на стороне сервера, но в случае сбоя код может стать видим обычным пользователям. Этого нельзя допускать, так как прочитав его, злоумышленники могут увидеть доступные файлы или базы данных с важной информацией, такой как, например, учетные данные.
Чтобы не допустить такого взлома, следует более внимательно отнестись к структуре каталогов вашего ресурса. Ни в коем случае не допускайте хранения важных файлов в каталогах, которые доступны всем пользователям, чтобы не допустить возможности, что их увидит кто-то, кроме вас.
Удаленный запуск файлов
Если ваш сайт содержит удаленные файлы, это тоже может стать причиной взлома, если эти файлы не доверенные. Если сайт, на котором хранятся ваши удаленные файлы, был взломан, то их код может быть заменен на вредоносный, который поможет хакерам во взломе вашего сайта. Поэтому нужно очень внимательно относиться к безопасности всех ресурсов, где располагаются ваши файлы.
Если же все-таки взлом стороннего ресурса произошел, то есть довольно простой способ устранить опасность. Для этого вам нужно в php.ini проверить состояние следующих флажков:
— allow_url_fopen. Эта настройка отвечает за то, могут ли внешние файлы быть включены в ваш сайт. По умолчанию это разрешено, чтобы это изменить, кликните по флажку.
— allow_url_include. Вторая настройка определяет, могут ли встроенные функции ссылаться на файлы, расположенные удаленно на других ресурсах.
Угон сессий
Угон случается, когда злоумышленник украл чужой идентификатор сессии и воспользовался им. Этот идентификатор играет роль ключа в защищенном соединении между клиентом и веб-сервером. В PHP этот идентификатор хранится у пользователя. Если ключ был украден, но во время сеанса пользователем не было совершено никаких важных действий, то ничего особо страшного не произойдет. Но если во время сессии пользователь осуществляет, скажем, аутентификацию, это может привести к неприятным последствиям, ведь хакер может завладеть данными для входа в аккаунт. Это особенно важно, если пользователь, совершающий вход, является администратором сайта.
ID сессии очень часто крадут с помощью описанного выше XSS скрипта. Поэтому защита от взлома с помощью XSS убьет сразу двух зайцев, и защитит вас еще и от угона сессий. Хорошим способом защиты именно от угона идентификаторов сессии является их регулярная смена. И чем чаще, тем лучше. Для того, чтобы сменить идентификатор в php вам нужно воспользоваться session_regenerate_id.
В случае, если вы используете PHP 5.2 или выше, то для защиты от угона идентификатора вы можете воспользоваться таким функциями, как:
session.cookie.httpolny и session_set_cookie_parms.
Для того, чтобы обеспечить безопасность вашему проекту, регулярно проводите поиск уязвимостей на php сайте. Ведь, если у вашего ресурса не будет уязвимостей, то хакерам не за что будет зацепиться и вероятность взлома будет крайне мала.
И, конечно, не забывайте, что защита вашего сайта определяется также надёжностью вашего хостинга. АдминВПС всегда заботится о безопасности ваших проектов, независимо от того, располагаются они на виртуальном хостинге или выделенных серверах.
Через какую дыру взломали сайт?
Если сайт взломан, мало удалить с него вирус и загруженный PHP Shell. Нужно еще найти причину, по которой произошел взлом, иначе через день-два на сайте снова будет под бодрую музыку развеваться красивый турецкий иностранный флаг. Чаще всего причина — украденный пароль от FTP, устаревшая версия CMS или плагина к ней, но как найти, что именно было использовано для проникновения?
Имея некоторый опыт в этой сфере (в среднем наша техподдержка занимается поиском причины взлома сайта раз в неделю), мы систематизировали накопившуюся информацию.
Итак, зачем вообще взламывают сайты? И что делать, если сайт взломан, как найти причину и защититься от последующих атак?
Зачем взламывают сайты
Алгоритм поиска причины взлома
Как искать следы взлома
Помимо файлов сайта стоит также проверить общий /tmp сервера — в нем могут находиться временные файлы, использованные для взлома или для запуска ботов.
Иными словами, необходимо искать все необычное/непонятное и заглядывать внутрь всех подозрительных файлов. PHP Shell может выглядеть, например, так:
Файлы можно искать и вручную, но быстрее, если взлом произошел недавно, воспользоваться командой find:
Если ничего не помогает, можно просто поискать все файлы, содержащие закодированное в base64 содержимое, например, так:
Определение времени взлома
Когда файлы найдены, определить время взлома очень просто — достаточно посмотреть время изменения самого раннего файла.
Если подозрительных файлов не найдено, но сайт заражен вирусом, посмотрите дату изменения файлов index.php, index.html или тех, в которых обнаружите вирус. Скорее всего в этом случае сайт взломали, украв пароль от FTP.
Поиск журналов взлома сайта
Теперь самое главное — чтобы эти журналы были в наличии!
Если на сайте только произведен дефейс или добавлен вирус ко всем файлам index.html, скорее всего, сайт взломали через кражу пароля FTP (или, гораздо реже, SSH). Посмотрите журналы подключения по FTP и SSH во время взлома — присутствие в нем неизвестных IP-адресов или большого количества разных IP-адресов, осуществивших успешное подключение к сайту, означает, что пароль украден.
В этом случае достаточно проверить компьютеры, с которых осуществлялся доступ к сайту, на вирусы, сменить пароли FTP и никогда больше не сохранять пароли в клиентах FTP.
Если же на сайте присутствуют PHP Shell или вредоносные скрипты (например, для рассылки спама), скорее всего, сайт взломали через уязвимость в CMS или каком-либо её плагине. В этом случае потребуется проанализировать логи веб-сервера.
Если удалось определить IP-адрес
Определив IP-адрес взломщика, мы производим поиск этого IP-адреса по журналу веб-сервера и видим все действия, которые он совершал. Где-то близко к моменту обращения к PHP Shell будет успешное использование уязвимости сайта.
Если определить IP-адрес не удалось
Описанный выше способ работает, если известно конкретное имя файла, через которое производилась работа с сайтом после взлома. Однако это имя не всегда известно. В этом случае придется поискать момент взлома немного подольше, но найти его все равно можно.
Большинству, подавляющему большинству взломов свойственны запросы HTTP POST, так как через них происходит загрузка файлов на взламываемый сайт. Через POST злоумышленник может также пытаться взломать форму ввода пароля или просто зайти в раздел администрирования с украденным паролем.
Если известно время взлома сайта (а мы его уже знаем), необходимо поискать в журнале веб-сервера все запросы POST, находящиеся близко ко времени взлома. Здесь нет конкретных советов — выглядеть они могут совершенно по-разному, но выглядеть они будут в любом случае необычно. Например, это могут быть запросы, содержащие ‘../../../../’ или длинные запросы, содержащие имена файлов или запросы SQL.
Если ничего не удалось найти
Такое тоже может быть. В этом случае можно порекомендовать только чистую переустановку CMS и ее расширений и последующий импорт данных. Обязательно убедитесь, что версия CMS и ее расширений — последняя.
И ее расширений! Чаще всего взломы производятся не через ядро системы управления сайтом, а через какой-нибудь устаревший плагин, автор которого давно забросил его разработку.
Ну и, разумеется, смените все пароли, которые имеют какое-либо отношение к сайту.
Уязвимости PHP-фреймворков
10 июня компания Digital Security провела онлайн-встречу по информационной безопасности Digital Security ON AIR. Записи докладов можно посмотреть на Youtube-канале.
По материалам докладов мы выпустим цикл статей, и первая из них — об уязвимостях PHP-фреймворков уже ждет под катом.
Что такое MVC
Большинство PHP фреймворков использует MVC — Model-View-Controller — концепцию разделения проекта на три отдельных компонента:
Компоненты независимы друг от друга, то есть внесение изменений в один из них не затронет другие.
Полезные уязвимости в PHP
Итак, что же искать в типичном проекте, созданном на PHP-фреймворке? Искать нужно все! Как ни удивительно, встретить можно любую уязвимость, так как ответственность за безопасность лежит в большей степени на разработчике проекта. Прежде всего нужно проверить, не включен ли режим отладки (исследователю это будет на руку; но если вы забыли выключить его на своем сайте, то поспешите это сделать). Режим отладки сильно поможет как в дальнейшем поиске уязвимостей, так и в их эксплуатации. Кроме режима отладки в любом проекте на PHP обязательно используются операторы сравнения для описания логики приложения. И тут скрывается еще одна уязвимость, типичная для PHP.
Рекомендую ознакомиться и с самим докладом, чтобы подробнее узнать об уязвимости.
Не менее распространенная уязвимость, из-за которой возможны большинство RCE, — это десериализация потенциально опасных данных. Дело в том, что в PHP можно сериализовать любой объект — преобразовать объект в строку, из которой его можно восстановить. Для восстановления строчку нужно десериализовать с помощью функции unserialize(). Уязвимость возникает, когда на вход этой функции подаются данные, контролируемые пользователем. Так он может собрать цепочку из классов, которые приведут к выполнению кода или чтению файлов на сервере. Тут стоит упомянуть phpggc — сборник уже готовых гаджетов (gadgetchains, цепочек из классов) для популярных PHP-фреймворков. Узнать больше об эксплуатации десериализации можно из доклада Павла Топоркова.
Каждый фреймворк состоит из набора пакетов, которые нужно как-то компоновать. На помощь приходит Composer, управляющий всеми зависимостями, который используется во всех фреймворках и сильно упрощает жизнь: все зависимости прописаны в одном файле composer.json. Все зависимые пакеты можно проверить на уязвимости с помощью сайта snyk.io просто передав ему composer.json. Также можно проверить только PHP-уязвимости с помощью специального инструмента — Security Checker.
Laravel
Всего было найдено четыре довольно критичных уязвимости в Laravel:
Рассмотрим возможность получения RCE.
Symfony
В PHP-фреймворке Symfony маршруты располагаются в директории config. Контроллеры находятся в директории src, представления — в директории templates.
У Symfony на cvedetails можно найти наибольшее количество CVE по сравнению с другими фреймворками. Среди них есть и пара очень старых RCE. Одна возможна из-за того, что при эксплуатации XSS в тэге script в параметре language можно указать язык PHP, и тогда PHP-код, указанный внутри тэга, выполнится на сервере. Вторая RCE, еще более старая, позволяет поместить PHP-код в специально сконфигурированный yaml-файл. При парсинге yaml-файла PHP-код выполнится на сервере.
Интересна история с обходом аутентификации. Сразу оговоримся, что CVE 2016 и 2018 года относятся к одному и тому же модулю аутентификации через LDAP. В 2016 году обнаружили, что процесс аутентификации можно обойти, используя пустой пароль (CVE-2016-2403). Уязвимость исправили, но допустили ошибку.
В 2017 году в другом модуле аутентификации нашли ту же проблему (CVE-2017-11365). В этот раз действительно исправили: введенный пользователем пароль сверяется не только с пустой строкой, но и с null. Это необходимо, потому что в языке PHP null не считается за пустую строку.
В 2018 году все-таки нашли ошибку в исправлении 2016 года (да-да, и такое бывает), которая позволяла обойти аутентификацию с помощью null, и закрыли ее (CVE-2018-11407).
Вот так можно было 2 года обходить LDAP с помощью null.
За последний год нашли еще несколько разнообразных уязвимостей на любой вкус. Некоторые из них легко эксплуатировать, например, уязвимости, заключающиеся в возможности header injection. Другие — например RCE — эксплуатировать довольно-таки сложно. Они новые, и модулей для них в phpggc нет, а работать с классами во фреймворках надо уметь. Так что если встретились с Symfony, уязвимым к этим багам, желаю удачи 🙂
Перейдем к фреймворку Yii. У него все не так, как у других, поэтому рассмотрим его более внимательно.
В Yii помимо типичных для MVC моделей, представлений и контроллеров, есть виджеты, модули и фильтры. Модули — это законченные приложения со своими данными, интерфейсами, логикой. В отличие от самих приложений, модули не могут быть развернуты отдельно: они должны находиться внутри приложений.
Фильтр — та же middleware, которая используется для шаблонных действий. Например, чтобы проверить, является ли пользователь администратором или является ли введенный e-mail валидным. Виджеты служат для создания сложных настраиваемых элементов пользовательского интерфейса. Например, с помощью виджета можно сгенерировать интерфейс выбора дат. Кроме того, в Yii нет конкретного файла с маршрутами. Все дело в том, что он сам строит маршрутизацию внутри сайта, используя контроллеры и действия. Соответственно, нам нужно либо вручную искать все контроллеры и все действия, либо писать чудо-скрипт, который сгенерирует файлик с маршрутами.
Из уязвимостей следует отметить три CVE:
Остановимся на первых двух поподробнее.
Утечка информации возникает, когда режим отладки выключен и исключения ловятся стандартной функцией. Так вышло, что при переходе на страницу About срабатывает исключение, режим отладки выключен, и мы не можем получить никакой дополнительной информации из этой ошибки. Но если на эту же страницу обратиться при помощи ajax-запроса, то внезапно мы получаем содержимое конфигурационного файла. Как же так? Все дело в том, что при ajax-запросе выдается сообщение, прописанное в исключении. Для наглядности мы поместили туда конфигурационный файл сайта. Однако, через такую уязвимость могут просочиться достаточно чувствительные данные (пароли или ключи), которые помогут при исследовании сайта.
Если вам повезло встретить проект, использующий Yii версии 1.1.14 и виджет CDetailView, в который передаются пользовательские данные, то вы сможете выполнять любой метод на сервере. На Github’е пишут, что таким образом можно выполнить любой PHP-файл в системе, но когда я попробовал это сделать, он не проходил условие, прописанное в функции run класса CDetailView, если не был явно подключен в коде.
Так мы передаем название класса и метода в запросе и видим содержимое конфигурационного файла сайта при помощи заранее добавленной секретной функции. Это все происходит потому, что параметр value проверяется функцией is_callable(), и если результат сравнения положительный, то он вызывается функцией call_user_func().
CakePHP
Фреймворк CakePHP структурно мало чем отличается от Laravel. Понятно, где искать модели, представления и контроллеры.
В нем так бы и были только лишь древние уязвимости (CVE-2010-4335, CVE-2012-4399), если бы не недавняя CVE-2019-11458 на десериализацию, при помощи которой можно перезаписывать файлы на сервере. Гаджетов пока что нет, поэтому будем ждать обновления phpggc.
Codeigniter
И, наконец, Codeigniter. Структура приложения понятная, все компоненты находятся на своих местах.
Из интересных уязвимостей можно выделить две старых (CVE-2014-8684, CVE-2016-10131) и одну относительно новую (CVE-2017-1000247). Первая из них настолько старая, что для нее есть модуль для Metasploit. Вторая встречается не только в этом фреймворке, но и во многих других PHP-фреймворках и PHP-приложениях. Более свежая CVE 2017 года — обычная header injection в функции set_status_header(). Рассмотрим поподробнее две старые уязвимости.
Первая уязвимость связана с сессией: зная ключ шифрования можно расшифровать cookie-файл и поставить себе права админа. Кроме того, можно загрузить полезную нагрузку, которая выполнится на сервере. Все это возможно из-за слабой криптографии (всего лишь XOR) и использования дефолтного ключа во многих проектах. В данном случае, эксплуатируя уязвимость, мы получаем права админа.
Заключение
Подводя итог, стоит сказать, что PHP-фреймворки просты и лаконичны. Наиболее критичные уязвимости существуют в старых версиях фреймворков, так что необходимо регулярно обновлять их, иначе пентест продукта может сразу выявить парочку RCE. Я разобрал и перечислил далеко не все уязвимости, и далеко не во всех фреймворках. Кто знает, сколько еще удивительных уязвимостей они хранят в себе. Увлекательных пентестов!