Учитывая тот факт, что взлом некоторых сайтов может принести немалую выгоду, а для того, чтобы его осуществить, преступнику даже не нужно выходить из дома, можно сделать вывод, что взлом сайта – очень заманчивое занятие для преступника. В дополнение к этому, злоумышленники в интернете очень редко несут наказания за свои деяния.
Но для того, чтобы взломать ресурс, хакер должен найти уязвимости в его работе. Пяти главным уязвимостям 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 сайте. Ведь, если у вашего ресурса не будет уязвимостей, то хакерам не за что будет зацепиться и вероятность взлома будет крайне мала.
И, конечно, не забывайте, что защита вашего сайта определяется также надёжностью вашего хостинга. АдминВПС всегда заботится о безопасности ваших проектов, независимо от того, располагаются они на виртуальном хостинге или выделенных серверах.
Этичный хакинг и тестирование на проникновение, информационная безопасность
С одной стороны, этот рассказ основывается на реальном случае аудита, то есть если бы я мог рассказать о нём без купюр, то получился бы кейс, из которого начинающие аудиторы безопасности веб-приложений или веб-мастеры и администраторы смогли узнать что-то новое, но, как и с любым кейсом, совсем необязательно, что в вашей практике будет что-то аналогичное и инофрмация окажется полезной.
Но, с другой стороны, о некоторых моментах я могу рассказать только в общих чертах. Поэтому в этой инструкции будет как никогда мало команд и скриншотов (может быть, вообще не будет). Поэтому это ещё и эксперимент: давным-давно я прочитал, что «каждая формула в книге уменьшает количество читателей вдвое». И автор этого высказывания делал вывод, что нужно без формул, объяснять, например, физику, «на пальцах» — тогда тиражи будут хорошим (и он заработает много денег — видимо, подразумевалось это). Я тогда подумал, что автор сильно не прав, но теперь мне кажется, что каждый запуск консольной утилиты в командной строке тоже уменьшает количество читателей статьи вдвое. ))))) В общем, если эта теория верна, то эта статья должна набрать много просмотров ))))
1. Поиск уязвимостей в веб-приложении
Сайт представлял собой написанное с нуля веб-приложение. Для использования функций требуется ввести логин и пароль, но предусмотрен гостевой вход, поэтому на сайте прямо на главной странице написаны гостевые учётные данные для входа.
Выполняемые действия сохраняются в Истории. У действия есть заголовок и определённый текст. Оказалось, что хранимые поля не фильтруются на специальные символы и слова, поэтому быстро удалось найти и подтвердить уязвимость XSS — то есть кода в поле вводишь что-нибудь вроде
а на странице сайта (в данном случае в История) показывает всплывающее окно JavaScript.
С помощью такой уязвимости можно, например, похитить кукиз других пользователей. Но проблема в том, что, видимо, История, у каждого пользователя своя. То есть максимум, что я могу сделать в этой ситуации, это захватить кукиз пользователей с точно такими же правами как у меня — то есть только у пользователей, выполнивших вход под гостевой учётной записью. Возможно, админу доступен список Истории всех пользователей — но не факт. Плюс надо ещё придумать, как спровоцировать его зайти в Историю — а то может получиться так, что в следующий раз он туда зайдёт через год, или через два, или никогда.
Поскольку видно, что специальные символы не фильтруются, а данные, скорее всего, хранятся в базе данных, то это может означать, что должна присутствовать уязвимость SQL-инъекция, которая позволяет получить базу данных сайта. Но я не успел это проверить — обнаружилась намного более лёгкая уязвимость — небезопасная выгрузка файлов.
Суть в том, что если я запускал новое действие, то мне для ввода были доступны несколько полей — в них я и обнаружил XSS и мог обнаружить SQL-инъекцию. Но при открытии сохранённого действия из Истории, на странице появлялось ещё одно поле — для загрузки файла.
У меня появилась умеренная радость: с одной стороны, на множество сайтов можно загружать файлы, но благодаря ограничению на расширения загружаемых файлов, а также способу доступа к ним, практически невозможно загрузить код, который можно выполнить на сервере. Но безалаберность с фильтрацией данных в текстовых полях вселяла некоторую надежду.
И загрузил его на сервер. Сервер показал мне ссылку на этот файл. То есть файл загрузился! Я перешёл по ссылке и вместо того, чтобы скачаться, либо чтобы показать содержимое — файл был выполнен, то есть я увидел ту информацию, которую показывает функция phpinfo().
В чём ошибки программиста:
Такой безалаберный стиль программирования нельзя совмещать с публичной учётной записью. То есть если бы на главной странице не были написаны учётные данные для входа, то поиск и эксплуатация этих уязвимостей сильно бы затянулись.
И более главное: при написании кода всегда нужно фильтровать данные и ограничивать файлы, которые можно загружать на сервер. Даже если вы программируете «для себя» и держите файлы на локальном сервере у себя на компьютере, всё равно может случиться неприятность — кто-то может подключиться к вашему веб-серверу по локальной сети (при использовании публичным Интернетом), или ваш компьютер может быть доступен напрямую по белому IP. Очевидно, что для публичного сайта код должен писаться с постоянной мыслью о безопасности.
2. Загрузка бэкдора
В начале я хотел воспользоваться самым простым вариантом — c99unlimited.php. Это шелл в фиде файлового менеджера и в нём удобно бродить по каталогам и скачивать файлы. Но у меня он не заработал — выдал ошибку 500. Видимо, у сервера с ним какая-то несовместимость.
Это абсолютно не проблема, разнообразных шеллов в Webshells очень много — можно долго сидеть и выбирать тот, который понравится, но я решил воспользоваться ещё более любимым Weevely. У меня к этому инструменту ещё более чувства )))) Хотя у него интерфейс командной строки — так мне нравится даже больше.
Создаём новый бэкдор (да, пароль просто цифра 1):
Заливаем его на сервер.
И подключаемся к нему:
3. Осматриваемся на сервере из бэкдора
Примечание: для лучшего понимания происходоящего, рекомендуется к знакомству цикл статей «Азы работы в командной строке Linux (часть 1)».
После подключения, Weevely показал, что я нахожусь в папке /var/www/XX1/tmp.
Можно дополнительно в этом убедиться:
Посмотрим, какие у меня права на эту папку:
Из этой информации следует, что владельцем папки является пользователей XX1. Но права на запись есть вообще у всех.
Кстати, а кто там я?
Я работаю от пользователя www-data.
4. Как скачать исходный код сайтов с сервера
Ах да, зачем я вдруг кинулся искать папку с правом на запись? Дело в том, что мне надо скачать файлы с исходным кодом — для дальнейшего анализа «в спокойной обстановке». Этих файлов много и скачивать их все по одному займёт много времени. Поэтому у меня план такой — запаковать все файлы в архив, а архив скачать.
Само собой, можно воспользоваться услугами папки /tmp, которая всегда открыта на запись для всех желающих. Но из папки /tmp я могу скачать только с помощью Weevely. Но если мне удастся сохранить архив в папку веб-сервера, то я могу скачать его прямо из веб-браузера или любой файловой качалкой. Это особенно актуально, если файл очень большой — может пригодиться докачка файла после разрыва соединения, что в командной строке с Weevely сделать не получится.
Понятно, что если мы в папке /var/www/XX1/tmp, то папкой веб-сервера является /var/www/. Посмотрим что там в ней:
А в ней папки других сайтов — в общей сложности 14 штук, но показать их я уже не могу.
Смотрим в шпаргалку, чтобы сохранить файлы в архив командой zip дополнительно нужно использовать опцию -r для рекурсивного добавления всего, что находится в папках, запускается следующим образом:
Каталогом для архивации является /var/www/, архив я пока сохраню в директорию /tmp (а не в папку с сайтами, так как получится, что мы попытаемся сохранить архив в папке, которая добавляется в этот архив — возможно, это вызовет ошибку).
На что мне возвращается сообщение:
Чёрт, на этом сервере не установлена программа zip. Можно воспользоваться встроенным эмулятором архивирования Weevely, но попробую ещё другую программу:
А вот программа tar оказалась на сервере. Внутренние команды означают:
- c — создать архив
- z — алгоритм сжатия
- f — после этой опции указывается путь до архива и имя файла
Переносим архив в папку веб-сервера, где он теперь доступен для скачивания даже с помощью браузера:
Чтобы узнать размер всех подпапок в папке /var/www/:
Если нужно скачать только некоторые папки, то это делается командой вида:
5. Как узнать, какие сайты работают на сервере
Исходный код — это очень ценный трофей и он нам ещё во многом поможет. Но, как я уже сказал, на этом сервере много папок с сайтами — то есть и сайтов здесь много.
Список всех загруженных настроек и обработанных виртуальных хостов можно узнать опцией -S. А с помощью -t -D DUMP_INCLUDES можно увидеть все используемые файлы конфигурации. Правда есть проблема — исполнимый файл веб-сервера может называться или httpd, или apache2 в зависимости от системы. На производных Debian файл будет называться apache2. А на производных Arch Linux — httpd. В принципе, проблемы никакой нет попробовать обе команды и посмотреть, какая из них сработает:
Как я уже сказал, в нормальных условиях эти опции должны показывать все конфигурационные файлы и все виртуальные хосты. Но, видимо, тот горе программист, который писал код для сайта, ещё взялся и за настройку веб-сервера — у меня вместо ожидаемой информации только выводится сообщение об ошибке в одном из конфигурационных файлов — не хватает SSL сертификата. Кстати, ведь это означает, что при перезапуске компьютера или только веб-сервера, — Apache, по идее, не запустится, так как это (вроде) фатальная ошибка.
Ладно, проверим вручную. Если бинарный файл называется apache2, значит конфигурационные файлы хранятся в /etc/apache2/.
В папке /etc/apache2/conf-available собраны другие конфигурационные файлы, а в папке /etc/apache2/conf-enabled можно узнать, какие из них подключены.
В папке /etc/apache2/mods-enabled можно посмотреть, какие модули Apache включены.
В папке /etc/apache2/sites-available можно узнать, настройки для каких сайтов предусмотрены, а в папке /etc/apache2/sites-enabled — какие из них активны в данный момент.
К сожалению, не могу вам показать содержимое, могу только сказать, в sites-available оказалось 18 конфигурационных файлов. В этих файлах для каждого сайта как минимум 2 обязательных директивы:
- ServerName — здесь имя хоста, фактически, домен сайта (иногда субдомен)
- DocumentRoot — путь до файлов на этом сервере для данного хоста
С помощью этой техники можно узнать, какие другие сайты хостит этот сервер, и где на сервере находится исходный код каждого из них.
Да чё уж там, берём всё, «дома разберёмся»:
6. Взлом MySQL
Если у нас есть доступ к файловой системе, то получение пароля от MySQL это дело техники.
Описанным выше способом (анализ виртуальных хостов и просмотр содержимого папок сайтов) находим адрес phpMyAdmin. Но phpMyAdmin может и отсутствовать — ничего страшного, можно работать с базой данных через консоль.
Самое главное, это проанализировать исходный код сайтов и найти там учётные данные. Чтобы упростить эту задачу, можно искать по содержимому файлов, особое внимание следует обратить таким строкам как:
- date_default_timezone_set
- mysqli_connect
- mysqli_query
- mysql_connect
- mysql_query
А также файлам с говорящими названиями, например, connectdb.php.
Weevely имеет команду для подключения к MySQL из командной строки:
Либо если MySQL разрешает удалённые подключения, можно подсоединиться к хосту напрямую:
Там внутри можно посмотреть базы данных:
Там же можно посмотреть таблицы в базе данных и содержимое таблиц.
Если нужно сделать дамп всех баз данных для скачивания, то это делается командой:
Между опцией -p и ПАРОЛЕМ нет пробела — иначе появляется ошибка.
7. Анализ добытых паролей
База данных раскрыла много интересной информации. Но самая интересная — это список пользователей с паролями.
У нас есть имена пользователей и пароли (а также email’ы и другая типичная для профилей информация). Пароль администратора для входа на сервис точно такой же, как и пароль пользователя root от MySQL. Напомню, если вы запутались: пароль от MySQL мы нашли в исходном коде файлов сайта, а пароль админа сервиса (сайта) мы нашли в базе данных. Хотя они оказались одинаковыми 
Это важно — пользователь имеет тенденцию использовать одинаковые пароли — это отдельная уязвимость, между прочим.
Но ещё интереснее анализ всех паролей пользователей — почти все они шестизначные числа! Видимо, учётные данные генерировал и выдавал администратор. У администратора склонность создавать однотипные пароли — учтём это. То есть если придётся брут-форсить службы на этом сервисе (а нам придётся 
), то я уже знаю, каким будет словарь — это будет полный список чисел из шести цифр.
Ну и вообще — если пароли одинаковые, то есть смысл поискать другие службы — вдруг туда тоже подойдут уже имеющиеся у нас логины и пароли.
8. Промежуточный итог
Итак: сервер скомпрометирован через уязвимое веб-приложение.
Уже на данном этапе:
- Получен доступ в файловую систему
- Получен доступ к исходному коду сайта
- Есть возможность редактировать файлы веб-сайтов
- Получен пароль от СУБД, получен доступ к базам данных, есть возможность редактировать базы данных
- Получены пароли пользователей от сервисов
- Анализ паролей выявил в них явную закономерность
- Найдены другие сайты и получен их исходный код
Можно уже сейчас составлять отчёт для владельца-заказчика и завязывать с этой оценкой безопасности.
Краткое содержание отчёта: всё плохо.
Но у этой истории будет ещё и вторая часть. Смотрите продолжение «Как взламывают сайты (часть 2)».
Опубликовано экстренное обновление web-фреймворка Apache Struts, применяемого для создания web-приложений на языке Java с использованием Model-View-Controller. В новых выпусках устранена критическая 0-day уязвимость (CVE-2017-5638), которая уже несколько дней используется злоумышленниками для получения контроля за сайтами, работающими под управлением Apache Struts.
Уязвимость позволяет выполнить произвольный код на сервере, отправив запрос со специально оформленным содержимым HTTP-заголовка «Content-Type». Проблема проявляется в выпусках Struts с 2.3.5 по 2.3.31 и с 2.5.0 по 2.5.10, и вызвана ошибкой в коде Multipart parser, применяемом для разбора запросов, состоящих из нескольких частей (multipart/form-data). В случае, если заголовок Content-Type содержит некорректное значение, срабатывает исключение для отображения сообщения об ошибке, которое, если в тексте присутствует маска «multipart/form-data», также приводит к вызову обработчика Multipart parser и выполнению произвольного кода, передаваемого через выражение OGNL.
Так как в открытом доступе опубликовано несколько вариантов рабочих эксплоитов и в сети уже зафиксирована автоматизированная вредоносная активность, эксплуатирующая данную уязвимость, всем пользователям Apache Struts рекомендуется в экстренном порядке выполнить обновление или блокировать работу компонента Jakarta Multipart parser, а также убедиться в отсутствии следов атаки на систему. Обновления пакетов с libstruts уже выпущено для Debian. В Ubuntu проблема остаётся неисправленной. В штатных репозиториях RHEL/Cent OS пакет Apache Struts не поставляется.
В случае если web-приложение выполняется в контейнере Apache Tomcat, запускаемом с правами root, в результате атаки сразу может быть получен root-доступ к системе. Например, фиксируемые в логах попытки атак выполняют отключение пакетного фильтра и устанавливают бэкдор для удалённого управления системой или типовое вредоносное ПО:
