Как взломать php файл

Обновлено: 06.07.2024

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

Предыстория

Я надеюсь, что тебе не надо объяснять, что такое phpMyAdmin и с чем его едят, поэтому перейдем сразу к его хладному трупу :). Седьмого июля некий буржуйский багокопатель под ником Mango обнаружил следующее интересное место в коде движка:

if (strstr($_SERVER['QUERY_STRING'],'session_to_unset') != false)
parse_str($_SERVER['QUERY_STRING']);
session_write_close();
session_id($session_to_unset);
session_start();
$_SESSION = array();
session_write_close();
session_destroy();
exit;
>

Ты спросишь, что в этом коде такого интересного? Обрати внимание на функцию parse_str(). В предыдущих выпусках журнала ты уже мог неоднократно прочитать о том, что при определенных условиях из-за данной функции может возникнуть баг с так называемой неконтролируемой глобализацией переменных. В данном случае такими условиями являются:

Отсутствие второго параметра в функции parse_str();
Полный контроль удаленного пользователя над переменной $_SERVER[‘QUERY_STRING’] (это то, что идет в ссылке после знака "?").

В первые несколько дней после обнаружения уязвимости никто не мог или не хотел вникать в ее суть (в том числе и я). Данная ситуация была крайне забавной, так как автор даже указал возможный вектор применения бага: перезапись глобального массива $_SESSION, эффект от которой сохранится даже после перезагрузки страницы.

Пример инжекта произвольных переменных в сессию выглядит так:

Так как переменные сессии принимают участие во множестве мест движка, теоретически может возникнуть куча XSS и SQL-дырок. Однако мы сфокусируемся на нескольких наиболее серьезных векторах.

Первый вектор атаки

Для понимания первого вектора атаки мы должны пройтись по исходному коду нескольких файлов. Сначала давай заглянем в код класса для автоматической генерации конфига ./setup/lib/ConfigGenerator.class.php:

public static function getConfi gFile()
.
$c = $cf->getConfi g();
.
$ret = '<?php ' . $crlf
.
if ($cf->getServerCount() > 0) .
foreach ($c['Servers'] as $id => $server) $ret .= '/* Server: ' . strtr($cf->getServerName($id), '*/', '-') . " [$id] */" . $crlf . '$i++;' . $crlf;
.

Теперь нам нужно разобраться в этой каше. Первым делом обрати внимание на то, что данный код генерирует PHP-листинг с конфигом для phpMyAdmin. Здесь можно заметить, что ключ массива $c[‘Servers’] (переменная $id) не фильтруется. Таким образом, если мы сможем переименовать этот ключ в массиве, то сможем закрыть комментарий и проинжектить произвольный код. Далее смотрим на функцию getConfig(), с помощью которой и получается нужный нам массив $c:

./libraries/confi g/Confi gFile.class.php

public function getConfi g()
$c = $_SESSION[$this->id];
.
return $c;
>

Бинго! Переменная $c полностью зависит от массива $_SESSION, который, как ты уже понял, находится под нашим контролем! Теперь мы легко сможем инжектнуть произвольный PHP-код, который будет сохранен в файл ./config/config.inc.php.

В данном способе эксплуатации нет никаких ограничений (вроде авторизации или обязательного отключения magic_quotes_gpc). Омрачает ситуацию лишь один факт — папка ./config не является дефолтной для движка, так что попасть в точку ты сможешь лишь один раз из ста.

Второй вектор атаки

Второй способ уже не зависит от наличия папки ./config на сервере. Зато появляются две другие зависимости: magic_quotes_gpc = On и наличие логина и пароля к любой из баз данных текущего mysql-сервера.

Начинаем потрошение исходников:

.
$trg_db = $_SESSION['trg_db'];
.
$uncommon_tables = $_SESSION['uncommon_tables'];
.
PMA_createTargetTables($src_db, $trg_db, $src_link, $trg_link, $uncommon_tables, $uncommon_table_structure_diff[$s], $uncommon_tables_fi elds, false);

Смотрим на функцию PMA_createTargetTables:

function PMA_createTargetTables($src_db, $trg_db, $src_link, $trg_link, &$uncommon_tables, $table_index, &$uncommon_tables_fi elds, $display)
.
$Create_Table_Query = preg_replace('/'. PMA_backquote($uncommon_tables[$table_index]) .'/', PMA_backquote($trg_db) . '.' .PMA_backquote($uncommon_tables[$table_index]), $Create_Query, $limit = 1);
.

Если ты внимательно следил за руками, то должен был заметить, что переменные $uncommon_tables[$table_index] и $trg_db переходят в функцию preg_replace() прямиком из массива $_SESSION. Так как я более чем уверен, что ты наслышан об одном из самых распространенных багов в PHP-движках — выполнении произвольного кода в preg_replace() с модификатором "e" (eval), перейдем сразу к делу. В данном случае мы можем проинжектить модификатор "e" в первый параметр уязвимой функции с помощью банального нуллбайта примерно так: (.+)/e%00. Все, что идет после нуллбайта, сразу же отпадет, и компилятор не будет ругаться на неправильно построенную регулярку :). Дабы не засорять страницы журнала килобайтами кода, демонстрирующего работоспособность этого и предыдущего способов эксплуатации нашего бага, я заботливо положил на наш диск соответствующие эксплоиты, с которыми и советую тебе ознакомиться.

Кстати, известный Suhosin patch от Стефана Эссера успешно закрывает багу с нуллбайтом и модификатором "e", так что здесь мы получаем еще одно суровое ограничение.

Тепличные эксплоиты

Теперь небольшое лирическое отступление. Уязвимость с перезаписью глобальных переменных сама по себе не является чем-то фатальным. Здесь нужно найти какой-либо вектор эксплуатации с любой из перезаписанных переменных. Это может не всегда получиться. В данном случае Mango нашел сразу два таких вектора, но эксплоиты по их мотивам получились крайне тепличными, необходимость авторизации и наличия недефолтной директории для успешного использования бага не давали нам ничего на практике.

Как ты уже понял, такая ситуация крайне меня не устраивала, поэтому после появления первых PoC я решил провести самостоятельное расследование. Здесь как нельзя кстати под руку подвернулся классный прошлогодний баг Стефана Эссера под названием "PHP Session Serializer Session Data Injection Vulnerability", который очень хорошо согласовывался с уязвимостью в unserialize() и "волшебных методах" PHP (ссылки на соответствующие статьи из прошлых номеров нашего журнала ищи в сносках).

Уязвимость в сессиях

Итак, остановимся немного подробней на вышеобозначенной уязвимости. По дефолту PHP-десериализатор сессий знает два специальных символа: PS_DELIMITER и PS_UNDEF_MARKER. Первый юзается для разделения сохраненных в сессии переменных, а второй маркирует неопределенные переменные и представляет собой обычный восклицательный знак. Заглянем в исходники PHP:

while (p < endptr) zval **tmp;
q = p;
while (*q != PS_DELIMITER) if (++q >= endptr) goto break_outer_loop;
>
if (p[0] == PS_UNDEF_MARKER) p++;
has_value = 0;
> else has_value = 1;
>

Проблема этого кода заключается в том, что сериализатор сессии корректно обрабатывает только символ PS_DELIMITER и забивает большой болт на PS_UNDEF_MARKER.

В результате своего исследования Стефан Эссер нашел способ внедрения произвольных данных (если быть точнее: строк, чисел, массивов и объектов) в сессию с помощью ключа массива $_SESSION, начинающегося с символа PS_UNDEF_MARKER. Примеры уязвимого к данной атаке кода выглядят так:

<?php
session_start();
$_SESSION[$_POST['prefi x'] . 'bla'] = $_POST['data'];
?>

<?php
session_start();
$_SESSION = array_merge($_SESSION, $_POST);
?>

Эксплуатация здесь выглядит крайне тривиально: посылаем POST-запрос prefi x=! и data=|xxx|O:10:"evilObject":0:<>.

В результате получаем инжект сериализованного объекта прямиком в сессии. Не забывай, что данное внедрение аналогично внедрению в функцию unserialize().

Вспоминая молодость

Если ты внимательно следишь за нашим журналом, то должен помнить, что в тех же статьях про "волшебные методы" я описывал классный способ эксплуатации бага с десериализацией во второй ветке phpMyAdmin. Тогда авторы поступили не совсем логично. Сама уязвимая функция unserialize(), конечно же, была убрана из исходников движка, зато полезный нам код в функции __wakeup() остался во всей третьей ветке совершенно нетронутым.

Теперь осталось только вспомнить механизм действия старого эксплоита, применить новые фишки и запилить новый убойный эксплоит. Итак, старый код для эксплуатации выглядел примерно следующим образом:

Здесь мы получали классический RFI-баг, омрачавшийся лишь проверкой на локальность с помощью мерзопакостной функции file_exists(), которая, впрочем, легко обходилась с помощью указания файла на любом доступном FTP-сервере.

Новая жизнь старых багов

Намотав на ус вышеописанную информацию, ты, наверное, уже понял, что теперь мы приступим к написанию универсального эксплоита для phpMyAdmin всей третьей ветки :). Сначала нам нужно узнать токен, с помощью которого движок проверяет валидность запросов (только с помощью валидного токена мы сможем сохранить в сессию произвольные данные). Делается это достаточно просто:

1. Заходим на главную phpMyadmin;

2. Парсим токен из HTML-исходника страницы, например, так:

preg_match( '@name="token" value="([a-f0-9])"@is',$page,$to);
$token = $to[1];

3. Таким же образом и с той же главной страницы парсим кукисы с идентификатором текущей сессии:

preg_match( '@phpMyAdmin=([a-z0-9]);?@is',$page,$se);
$session = $se[1];

4. Теперь пытаемся узнать текущий путь к папке с сессиями для успешного инклуда. Делается это с помощью простейшего цикла while и списка наиболее популярных мест в системе:

$sess_path = array(
'/tmp/',
'/var/tmp/',
'/var/lib/php/',
'/var/lib/php4/',
'/var/lib/php5/',
'/var/lib/php/session/',
'/var/lib/php4/session/',
'/var/lib/php5/session/',
.

Сам запрос для проверки на корректный инклуд в цикле выглядит примерно так:

Здесь: $sess_path[$o] — это каждый путь из массива $sess_path по порядку, $session — полученный выше идентификатор сессии, $pma — путь к движку, $token — полученный выше токен. Запрос $query следует посылать два раза: в первый раз происходит сам инжект, а во второй — проверка корректности пути к сессии. Если путь правильный, произойдет успешный инклуд, и мы увидим на экране содержимое файла сессии. Отследить инклуд можно по ключевому слову "PMA_Config". После успешного инклуда ты можешь спокойно внедрять свой PHP-код. Внедрение можно произвести с помощью все того же бага с переопределением глобальных переменных:

Наша переменная payload попадает в файл сессии, после чего мы вполне сможем выполнить код при помощи описываемого RFI. Готовый эксплоит с сессиями ты также сможешь найти на нашем диске. Здесь хочу заметить, что, хотя данный способ и является более универсальным, чем способы Mango, он тоже несколько ограничен: magic_quotes_gpc = off и PHP <= 5.2.13 & PHP <= 5.3.2. Данные ограничения все же ничто по сравнению с необходимостью наличия нестандартной открытой на запись папки на сервере.

Злоключение

Как видишь, любой когда-либо обнаруженный баг может еще вернуться и нанести свой удар по известнейшим программным продуктам. Особенно доставляет в данной ситуации тот факт, что наконец-то нашлось практическое применение для бага с сессиями Стефана Эссера (пока что в паблике не было ни одного PoC по теме). Тебе же я могу посоветовать никогда не смотреть на крутость и известность движка, а просто брать и потрошить его :).

Warning

Ни автор, ни редакция не несут никакой ответственности за любой возможный вред, причиненный материалами данной статьи.

Существуют несколько способов взлома сайтов. Самый распространённый взлом происходит через подбор пароля. К сожалению, даже в 21 веке администраторы ленятся делать надёжные пароли. Поэтому рекомендуем использовать наш "Генератор паролей".

Следующим по списку стоит взлом через уязвимости сайта. К примеру, SQL инъекция. От неё можно защититься только грамотной обработкой входящих данных. Которые включают в себя не только GET и POST, но и COOKIE (и др.способы хранения, которые используются сайтом).

Помимо этого существует целый класс атак через загрузку файла на сервер. Но в отличии от предыдущих способов, от него есть довольно простая защита. Её можно сделать через файл .htaccess, о котором пойдёт речь далее.

Отключение PHP в папке через .htaccess

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

Загрузка PHP файлов на сервер происходит через формы, где есть возможность добавить файл. К примеру, в разделе управления личными данными пользователей можно загрузить аватар пользователя. Но если обычный пользователь загружает картинки с расширением JPEG, PNG, GIF и т.п., то атакующий будет пытаться загрузить файл .PHP, который содержим вредоносный код. Этот код может делать всё, что угодно. К примеру, полностью удалять сайт.

Первый уровень безопасности должен заключаться в проверке расширения загружаемых файлов. На PHP он может быть реализован таким кодом: Этот код будет пропускать на сохранение только файлы, у которых в конце имени файла стоит или "jpg", "jpeg". Но иногда бывает, что загрузка файлов реализована внутри CMS, и отсутствует возможность изменить код загрузчика (потому что при следующем обновлении CMS он затрётся). При этом хочется обезопасить сайт. Тогда выход один - запретить исполнение файлов в папке, куда загружаются файлы. Делается это путём добавления в неё файла .htaccess, содержащего специальные директивы, отключающие обработку PHP скриптов в папке. Чтобы скрипты при их вызове открывались как текстовые файлы, а не исполнялись.

Небольшая история о неадекватном заказчике и нахождении уязвимости на сайте за 1 минуту.

Не ожидал, что именно эта история станет моей первой статьей на Хабре. Пишу пока горячо!

Изучил trello. Над проектом работали, если верить доске, как минимум 4 разработчика.

6 апреля 2020 г.

Из-за карантина, по-моему, люди начинают сходить с ума. Вот что я увидел в whatsapp когда проснулся:

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

Ничего не оставалось, кроме как пробраться на проект «обидчика» и избавиться от неприятных ощущений внутри :D.

Вижу форму поиска и пытаюсь проверить ранее известную мне SQL инъекцию:

Как и предполагал — не работает, но попробовать стоило.

На сайте есть возможность зарегистрироваться двумя способами: как Юзер и как Компания.

Исходя из увиденных в trello скриншотов, решил зарегистрироваться и поработать с личным кабинетом Компании.

Заполняем поля везде, где позволит фронт строками

Просто, чтобы усилить «эффект присутствия» у разработчиков, когда они заглянут в БД.

После успешной регистрации нас редиректит на страницу профиля Компании.
Открываем пункт меню «Load Documents» (очень удобно, не правда ли :D) и пытаемся загрузить php файл.

Сначала я загрузил adminer.php, так как он был под рукой. Файл успешно загрузился и разработчики заботливо подготовили для меня редирект на страницу с ссылкой на файл.

Открывался он по ссылке: /upload/certified/15861775921.php и исправно работал.

Это было начало конца!

Далее загружаем самый простой php-web-shell через ту же форму.

Для начала нужно понять, кто мы и где мы:

Посмотрим список файлов директории сайта:

Видим стандартную структуру фреймворка Yii2, которую мы там и ожидали.

Получаем доступы к базе данных, которые можно ввести в ранее загруженный adminer.php:

На самом деле был удивлен, что такие уязвимости еще существуют. А уж тем более тем, что их можно найти так легко и быстро.

Кстати, это был проект одной компании из ОАЭ, которая занимается поставкой буровых и промышленных изделий для нефтяной, газовой и буровой промышленности.

Не забывайте делать проверку типов файлов на стороне сервера, да и в целом уделяйте безопасности вашего кода больше внимания!

Знать о том, как хакеры ломают сайты – необходимо тем, кто хочет защитить свой сайт от взлома. А также необходимо знать, насколько легко (сейчас в Интернете) раздобыть код для взлома и как можно сайт сломать через подбор пароля. Именно об этом мы и поговорим сегодня. Ведь зная, как действуют хакеры, и какие есть методы взлома, Вы сможете ликвидировать у себя все несовершенства и уязвимости. Все эти знания помогут Вам сохранить свой сайт и свои данные!

Представляем Вам: 4 метода как хакеры ломают сайты, а 1 метод для взлома телефона или компьютера простым (неподкованным в программировании) людям.

Метод 1. Межсайтовый скриптинг или XSS-атака на веб-сайт

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

Шаг 1. Хакеры находят из тысячи сайтов уязвимый

Перед тем как сайт сломать, хакеры отыскивают наиболее уязвимый. К таким уязвимым веб-сайтам относятся сайты знакомств, доски объявлений, отзовики. Т.е. те сайты, который предоставляют возможность посетителям писать абсолютно любой текст. Подумайте – не входит ли в этот список Ваш сайт?

Шаг 2. Пишут на сайт текст (пост, отзыв, комментарий, поле поиска)

А нужно это для того, чтобы узнать, отсеивается ли системой данный код для взлома. Потом нужно просто нажать на созданный комментарий – если появится предупреждение – все, такой сайт можно взломать, он уязвим.

Шаг 3. Создают и загружают свои скрипты

Этот шаг особенно важен, так как он позволит собрать cookie, в которых хранятся учетные записи пользователей со всеми данными. Вот таким образом можно узнать логины и пароли аккаунтов. Но… если это сайт уязвим, а пароль не проходит хеширование. Т.е. не шифруется самой системой так, чтобы обратно пароль не возможно было расшифровать и перевести в нормальный первоначальный вид.

Для этого используют специальные php-скрипты. Скрипт начинает воровать данные из взломанного сайта и пересылать их на сервис мошенникам.

Шаг 4. Публикуют JavaScript-код

Шаг 5. Получают cookie со всеми данными

Чтобы уберечься от этого метода вскрытия сайтов, Вам нужно знать, что такое JavaScript-код, какой-нибудь язык программирования и хоть немного язык HTML. Если Вы хотите защитить свой сайт от взлома, необходимо постоянно обучаться, разобраться что такое дыры в безопасности сайтов, какие они бывают и как они проявляются.

Теперь вы тоже знаете, как хакнуть сайт при помощи межсайтового сриптинга и как сделать так, чтобы его от этого защитить.

Метод 2. Взлом веб-сайтов с уязвимостью SQL инъекции

Этот метод о том, как вскрыть сайт с обычного смартфона простым, который можно скачать в Плей Маркете, приложением Termux. Этим методом хакеры пользуются также интенсивно.

Шаг 1. Скачивают программу Termux

Скачивают и устанавливают на телефон Termux. В настройках программы прописывают следующие команды: pkg upgrade, pkg update, pkg install git, pkg install python, pkg install wget, python sqlmap.py

Шаг 2. Выставляют параметры

Параметры можно увидеть после того, как вы впишете последнюю команду и добавите – h. Выйдет целая куча различных параметров. Но ничего страшного в них нет. И перед тем, как ломануть сайт, пожалуйста, выучите английский. Он действительно будет нужен.

Шаг 3. Вскрывают нужную информацию

Итак, хакеры получили параметры и теперь они, прописав команду python sqlmap.py-u, вскрыли базу данных. Английская буква «u» показывает, что хакеров интересуют юзеры, а точнее пользователи данного сайта, а еще точнее – их конфиденциальные данные.

Всё, если пароль не прошел на этом сайте хеширование, то больше хакерам делать нечего – вся необходимая информация у них уже на руках. Сайт успешно взломан.

Метод 3. Таблицы возможных паролей

Существует огромное количество таблиц (целых баз) где прописаны всевозможные пароли. Вернее не паролей в чистом виде, как привыкли видеть мы, простые люди, а прошедшие хеширование (своего рода шифрование), которое невозможно расшифровать обратно.
Шаг 1. Взламывают веб-сайт и копирую себе все данные
Сначала хакеры ломают базу данных веб-сайтов. Там вытаскивают конфиденциальную информацию пользователей (Ф.И.О, возраст, адрес почты и логин). Но пароль там виден, только в хешированном виде.
Шаг 2. Вводят пароль в «радужную таблицу»
Заносят нужный пароль в таблицу и ждут, пока программа не найдет похожий хеш. Как только похожий пароль найден, это значит, что у хакера на руках появляется нормальный вид пароля (так, как ввел его пользователь при регистрации).
Шаг 3. Продают или взламывают аккаунт
Теперь, имея на руках логин и пароль, хакеры используют их по своему усмотрению. Однако… если логин достаточно сложный и не похож на стандартный, то отыскать его хеш в таблице – невозможно! В таблице находятся миллиарды стандартных паролей.

Запомните! Бессмысленный набор цифр и букв – это самый надежный пароль, который взломать – невозможно!

Метод 4. Фишинговая страница

Это еще один метод, позволяющий осуществлять вскрытие сайтов. Он основан на создании фишинговой (ложной) страницы для входа в определенную социальную сеть. Человек вносит туда свои данные, хакер перехватывает их – всё! Об этом очень подробно описано в статье « Как самостоятельно взломать Инсту: 7 рабочих методов » и « Как прочитать чужой Контакт ».

Метод 5. Специальные программы для слежения

Теперь и Вы знаете, как хакеры ломают сайты. Вы видите, что для этого нужны определенные знания и навыки. Но… если Вы далеки от программирования, воспользуйтесь специальными программами для слежения, которые нужно просто установить на подконтрольное устройство (телефон, планшет, ноутбук или компьютер).

С ними Вы сможете ознакомиться в статье « Топ 15 лучших программ для слежки за телефоном » – это тоже поможет понять, как взломать что-либо. Это своего рода взлом сайтов, только доступный обычным пользователям, таким как ревнивым супругам, заботливым родителям или руководителям компаний и организаций:

Одним словом, людям, далеких от программирования и хакерских заморочек!

Как защитить свой сайт от хакеров

Защита сайта должна ложиться на плечи разработчика, хостера и администратора. Самые простые, но очень действенные способы защиты (которые почему-то часто игнорируют) – это типа, мойте руки и фрукты перед едой, но многие не моют, а потом болеют глистами, желтухой и еще фиг знает какой заразной дрянью.

Простые (примитивные), но очень действенные способы защиты от вскрытия сайтов:

В заключении хочется отметить, что данная статья написана исключительно для ознакомления возможных методов взлома. Просто описана сама суть взлома, без какой либо технической информации. Это сделано специально, чтобы не знающие, так и не поняли, как ломать сайты, а знающие увидели, как защитить сайты.

Есть вопросы? Пишите нашим консультантам. Мы рады помочь Вам!

Читайте также: