Rebz
20.02.2015, 14:24
Этой статьёй мы начинаем серию материалов, посвященных поиску уязвимостей в популярных системах с открытым кодом. Ошибки в OpenSSL и glibc показали, что тысячи глаз (https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BA%D0%BE%D0%BD_%D0%9B%D0%B8%D0%BD% D1%83%D1%81%D0%B0), имеющих доступ к коду, — не гарантия безопасности open source. Конечно, и закрытый код не становится безопаснее от самого факта закрытости. Просто при наличии правильных инструментов доступность исходного кода позволяет выявить гораздо больше уязвимостей, чем при тестировании методом «чёрного ящика». Вопрос лишь в том, кто этим воспользуется раньше – разработчики или злоумышленники.
http://habrastorage.org/getpro/habr/post_images/f9f/a0f/590/f9fa0f590c16e759e1e56cbea51f13d9.jpg
Последние два года в ходе разработки системы анализа исходных кодов PT Application Inspector мы проверяли на стендах и «в поле» сотни бесплатных и коммерческих, открытых и проприетарных приложений. В ходе этих тестов было найдено значительное число уязвимостей нулевого дня. Часть этих проблем была закрыта и известна по последним докладам о безопасности SCADA (http://habrahabr.ru/company/pt/blog/247129/), часть ожидает своей погибели в ходе ответственного разглашения.
Воспользуемся же открытостью open source и покажем, как выявляются и анализируются уязвимости в исходном коде. В роли первого подопытного выступает бесплатная система управления сообществами InstantCMS, работающая на PHP и MySQL. На базе данного конструктора создано немало (http://www.cmsmagazine.ru/catalogue/instantcms/works/?sk=tcy&so=desc&st=&bt=&server=&cpp=30&pn=1) социальных сетей, сайтов знакомств, онлайн-клубов, городских порталов и государственных ресурсов.
В настоящее время разработчик InstantCMS устранил все обнаруженные нами уязвимости. В этой статье мы рассмотрим ошибки той версии, которая была актуальна на момент тестирования — в ней было найдено несколько десятков багов разной степени риска. Ниже описаны самые интересные.
В любой CMS есть хотя бы одна XSS
Исследуя код InstantCMS, наш анализатор сообщил о возможности проведения атаки XSS (межсайтовое выполнение сценариев) вот в таком формате:
http://habrastorage.org/getpro/habr/post_images/fdd/1cc/7ae/fdd1cc7ae7c80e295cc952b5508f8913.png
Рис. 1.1. Сообщение о наличии XSS-уязвимости
В сообщении приводится полное имя скрипта, номер строки и непосредственно сам код, содержащий уязвимость. Эта информация важна для разработчика: теперь он может найти ошибку, которая стала причиной этой уязвимости.
Теперь для проверки наличия уязвимости посмотрим на автоматически сгенерированный эксплойт, а также на условия, при которых эксплуатация ошибки будет успешной.
http://habrastorage.org/getpro/habr/post_images/e44/805/f16/e44805f16ce3f44b7ea31f819509fdce.png
Рис 1.2. Подробная информация о найденной XSS
Очевидно, что условие истинно только тогда, когда в запросе будет передан конкретный параметр:
textinputs[]='alert(1)'
Проверим, как это работает на практике. Отправляем на сервер эксплойт и получаем ответ:
http://habrastorage.org/getpro/habr/post_images/1a1/725/7ea/1a17257eae3b714fc26e6343882fe29e.png
Рис 1.3. Запрос и ответ сервера
Как видим, ответ сервера в HTML-странице содержит именно тот JavaScript-код, который мы отправляли в эксплойте.
Итак, мы убедились, что уязвимость существует. Самое время покопаться в коде и найти ошибку программиста. Воспользуемся информацией из Application Inspector, а именно — полным именем скрипта, номером строки и самим кодом, содержащим уязвимость (см. рис. 1.2).
Проанализировав исходный код, получаем такую картину:
Файл spellchecker.php:
17 строка: $textinputs = $_POST['textinputs'];
…
function print_textinputs_var() {
global $textinputs;
foreach( $textinputs as $key=>$val ) {
27 строка: echo "textinputs[$key] = decodeURIComponent(\"" . $val . "\");\n";
}
}
…
161 строка: print_textinputs_var();
Функция print_textinputs_var () объявлена в верхней части этого же скрипта и как раз содержит известную нам строку номер 27, в которой происходит вызов опасной функции “echo”:
Анализ показал, что код в строке 17 содержит недостаток — нефильтрованный параметр $_POST['textinputs'] — который и стал причиной уязвимости в строке 27. А это, в свою очередь, сделало XSS-атаку возможной.
Чего можно добиться с помощью XSS? Как минимум инвайта (http://habrahabr.ru/post/197466/) на Хабре А если звезды сойдутся — получить в свое распоряжение cookies администратора сайта, а следовательно, и доступ в админскую панель.
Уязвимость HTTP Response Splitting
В ходе дальнейшего сканирования была обнаружена возможность провести атаку, основанную на расщеплении HTTP-ответа сервера (HTTP Response Splitting):
http://habrastorage.org/getpro/habr/post_images/5ed/d17/072/5edd170724439788fe7d731da2c45c58.png
Рис 2.1. Отчет Application Inspector (справа — уязвимость в деталях)
Сгенерирован классический тестовый эксплойт, добавляющий дополнительный заголовок путем внедрения символов «перевод строки» и «возврат каретки». Эксплуатация возможна, если приложение работает на PHP версии ниже 5.1.2 (в более поздних версиях в интерпретатор встроена защита от таких атак).
http://habrastorage.org/getpro/habr/post_images/c30/c0b/a16/c30c0ba16f9c816a73d3d39b015f5f8a.png
Рис. 2.2. Граф потока выполнения демонстрирует наличие уязвимости
Результат анализа позволяет найти причину возникшей уязвимости и выработать рекомендации по ее устранению. Система PT AI указала, что вызов опасной функции произошел на 32-й строке файла set.php. Открыв исходный код, мы действительно видим, что в означенную строку попадает параметр, принимаемый без всякой фильтрации из POST-запроса в 15-й строке того же файла.
http://habrastorage.org/getpro/habr/post_images/26c/65f/348/26c65f348a771c82f191c27ee2238419.png
Рис 2.3. Программный код, содержащий уязвимость
Бывают случаи, когда разбор причин возникновения уязвимости является значительно более трудоемким, однако в данном случае и причины возникновения уязвимости, и пути ее устранения очевидны. Программисту необходимо добавить дополнительные проверки при присвоении значения переменной $back.
Уязвимость Open Redirect
В результате сканирования была обнаружена возможность провести атаку, классифицируемую как Open Redirect — открытое перенаправление:
http://habrastorage.org/getpro/habr/post_images/6a9/7f9/71a/6a97f971a7425b2e1631a2dbce95a04a.png
Рис 3.1. Отчет о наличии Open Redirect, с подробной информацией
Воспользуемся автоматически сгенерированным запросом-эксплойтом: отправим его на сервер-стенд и проанализируем ответ.
http://habrastorage.org/getpro/habr/post_images/862/354/e19/862354e19a9691d73dba930f72370a4b.png
Рис 3.2. Запрос-эксплойт для проверки уязвимости Open Redirect и ответ на него
Как мы видим, в исследуемой CMS действительно имеет место открытое перенаправление: ответом на запрос стала страница стороннего ресурса, переданная в векторе атаки. Попробуем разобраться в причинах. Отчет говорит о том, что точкой выхода атаки является строка 32 файла set.php. Откроем программный код:
http://habrastorage.org/getpro/habr/post_images/aba/2eb/634/aba2eb6348e9b08ccc0abd48e5634198.png
Рис 3.3. Уязвимый участок программного кода
В 32-й строке формируется заголовок location со значением из переменной $back. В свою очередь, переменная $back принимает свое значение из массива $_POST в 15-й строке того же файла без всяких дополнительных проверок. Таким образом становится ясна причина уязвимости — передача нефильтрованного параметра в 15-й строке файла set.php. Для устранения ошибки необходимы дополнительные проверки для переменной $back.
Чем опасна эта уязвимость? Прежде всего — возможностью практически незаметно для пользователя перенаправить его на зараженную страницу, а затем, так же незаметно, вернуть обратно.
Сплитинг и редирект в свежей PHP и Internet Explorer
Сплитинг с использованием последовательности символов %0D%0A работает на версиях PHP ниже 5.1.2, однако в некоторых ситуациях он возможен, даже если на сервере используется современная версия PHP.
Подходящие условия возникают, если клиентом является браузер Internet Explorer: он понимает последовательности %0A%20 или %0D%0A%20 как разделитель, а другие браузеры считают новую строку, начинающуюся с пробела, продолжением предыдущего заголовка. Такое поведение IE и недостаточная фильтрация в функции header() в PHP делают сплитинг возможным. Баг в header() исправлен недавно (bugs.php.net/bug.php?id=68978 (http://bugs.php.net/bug.php?id=68978)) и скоро попадет в релизы.
Примеры внедрения заголовка и содержимого в IE — ниже, адрес для проверки: molnar.es/php-header/test.php.
http://habrastorage.org/getpro/habr/post_images/c5b/bf4/72d/c5bbf472dfd5fcfcdbf01391c4ca325f.png
Рис. 4.1
http://habrastorage.org/getpro/habr/post_images/f70/c52/070/f70c52070f2895230e4eb710b99f3a48.png
Рис. 4.2
Проверить внедрение заголовков и открытое перенаправление на уязвимом сценарии (InstantCMS set.php в IE) можно и с помощью AI. Возьмем информацию из двух эксплойтов, полученных AI (адрес, метод, нефильтруемый параметр) для демонстрации такого вектора атаки на примере ptsecurity.com. Сделаем форму, которая посылает нужный вектор на нужный адрес, и посмотрим, работает ли атака. Как видим, да: на рис. 4.4 видно и адрес скрипта (set.php), и редирект (302-й статус и потом загрузку ptsecurity.com) и сплитинг (заголовок custom header).
Теперь по шагам:
1. Создаем страницу с формой:
http://www.ptsecurity.com/
Custom-Header: Test
2. Заходим на страницу в IE и отправляем запрос.
Результат выполнения запроса:
http://habrastorage.org/getpro/habr/post_images/9be/a84/125/9bea84125bcd008bd057d2007dcb4167.png
Рис. 4.3
http://habrastorage.org/getpro/habr/post_images/fa9/007/d1a/fa9007d1a833e9fbe4376c72993238d6.png
Рис. 4.4
На рис. 4.4 видно, что помимо перенаправления был установлен заголовок Custom-Header со значением Test.
SQL Injection
Рассмотрим еще один пример уязвимости, обнаруженной при помощи AI. Согласно результатам сканирования, в InstantCMS возможно внедрение SQL-кода (SQL Injection), да еще и в различных вариантах.
http://habrastorage.org/getpro/habr/post_images/faf/c56/bb5/fafc56bb539843ecd74adccc7bfec3ed.png
Рис. 5.1. Фрагмент отчета PT AI. Однотипные SQL-инъекции — и подробная информация об одной из них
Помимо определения уязвимого фрагмента кода и родительской уязвимости в приложении, PT AI выдает необходимые условия для проведения атаки.
На рис. 5.1 видно, что для эксплуатации SQL Injection требуются несколько условий, одно из которых — наличие в сессии вектора атаки. Это признак межмодульных уязвимостей (Second Order SQL Injection, хранимых XSS). У таких багов данные попадают в уязвимую функцию не сразу из переменных от точек входа, а из каких-то промежуточных хранилищ — базы, сессий и т. п., где они до этого каким-то образом оказались.
Эксплуатация межмодульных уязвимостей происходит в несколько этапов. Например, для хранимой XSS данные одним запросом заносятся в СУБД, а вторым запросом — извлекаются оттуда и чем-то выводятся на страницу.
http://habrastorage.org/getpro/habr/post_images/1ad/f65/9c9/1adf659c9bcb42b6100ac7d52aaa19c5.png
Рис. 5.2. Схема эксплуатации хранимых XSS
Продемонстрируем эксплуатацию найденной уязвимости Second Order SQL Injection в условиях, которые позволяют злоумышленнику изменять значения переменных в сессии. Возьмем простейший пример — виртуальный хостинг с общим хранилищем сессий. У хостинга есть ошибка конфигурации — значение директивы PHP session.save_path, которое по умолчанию равно /tmp (подробности (http://php.net/manual/en/session.configuration.php#ini.session.save-path)).
Если на сервере крутятся несколько сайтов, один из которых подконтролен злоумышленнику, мы можем атаковать соседний ресурс, функционирующий на базе InstantCMS, обладая минимальными правами.
Для этого необходимо:
1. Создать файл сессий с вектором для SQL Injection.
2. Сделать запрос с cookie, соответствующим файлу сессии из п. 1, к странице InstantCMS, при генерации которой вектор из сессии попадет в SQL-запрос.
Пример PHP-скрипта, генерирующего файл:
' . $output . '';
?>
Атака проходит в два этапа:
Сначала запускается скрипт, который создает файл с вектором и выводит значение для cookie сессии.
http://habrastorage.org/getpro/habr/post_images/d4e/9fb/4a9/d4e9fb4a9cfab48033cd657168be6e34.png
Рис. 5.3. Пример файла с вектором для SQL Injection в InstantCMS
Затем отправляется следующий запрос на сайт с InstantCMS:
GET /admin/index.php HTTP/1.1
Host: victim
Cookie: PHPSESSID=session
Connection: close
Ответ сервера будет получен примерно через 5 секунд для вектора с sleep(5), что подтвердит наличие SQL Injection.
Стоит подчеркнуть еще пару моментов:
Описанный сценарий атаки не сработал бы в случае, если бы в коде InstantCMS разработчики устанавливали значение session.save_path, которое бы отличалось от значения для сайта атакующего, и права на директорию с сессиями не давали получать список файлов, читать, изменять их и создавать свои.
Иногда встречаются баги с инъекцией в сессию (1 (http://www.php-security.org/MOPB/PMOPB-46-2007.html), 2 (http://www.php-security.org/2010/05/31/mops-2010-060-php-session-serializer-session-data-injection-vulnerability/index.html)) — как в самом PHP, так и в коде приложений.
Уязвимость SQL Injection позволяет провернуть множество нехороших фокусов, от чтения содержимого таблиц БД до заливки на сервер веб-шелла, это наиболее опасный вид атаки среди рассмотренных в данной статье. Об ошибках управления сессиями можно почитать в презентации (http://2013.zeronights.ru/includes/docs/Andrey_Danaw_-_Session_management_errors_in_cloud_solutions_and_ in_classic_hosting_systems.pdf) на ZeroNights, где показывали похожий случай ошибки управления сессиями применительно к CMS.
На этом с InstantCMS — все. Исследование уязвимостей в других системах с открытым кодом мы продолжим в следующих материалах.
Источник: http://habrahabr.ru/company/pt/blog/250675/
http://habrastorage.org/getpro/habr/post_images/f9f/a0f/590/f9fa0f590c16e759e1e56cbea51f13d9.jpg
Последние два года в ходе разработки системы анализа исходных кодов PT Application Inspector мы проверяли на стендах и «в поле» сотни бесплатных и коммерческих, открытых и проприетарных приложений. В ходе этих тестов было найдено значительное число уязвимостей нулевого дня. Часть этих проблем была закрыта и известна по последним докладам о безопасности SCADA (http://habrahabr.ru/company/pt/blog/247129/), часть ожидает своей погибели в ходе ответственного разглашения.
Воспользуемся же открытостью open source и покажем, как выявляются и анализируются уязвимости в исходном коде. В роли первого подопытного выступает бесплатная система управления сообществами InstantCMS, работающая на PHP и MySQL. На базе данного конструктора создано немало (http://www.cmsmagazine.ru/catalogue/instantcms/works/?sk=tcy&so=desc&st=&bt=&server=&cpp=30&pn=1) социальных сетей, сайтов знакомств, онлайн-клубов, городских порталов и государственных ресурсов.
В настоящее время разработчик InstantCMS устранил все обнаруженные нами уязвимости. В этой статье мы рассмотрим ошибки той версии, которая была актуальна на момент тестирования — в ней было найдено несколько десятков багов разной степени риска. Ниже описаны самые интересные.
В любой CMS есть хотя бы одна XSS
Исследуя код InstantCMS, наш анализатор сообщил о возможности проведения атаки XSS (межсайтовое выполнение сценариев) вот в таком формате:
http://habrastorage.org/getpro/habr/post_images/fdd/1cc/7ae/fdd1cc7ae7c80e295cc952b5508f8913.png
Рис. 1.1. Сообщение о наличии XSS-уязвимости
В сообщении приводится полное имя скрипта, номер строки и непосредственно сам код, содержащий уязвимость. Эта информация важна для разработчика: теперь он может найти ошибку, которая стала причиной этой уязвимости.
Теперь для проверки наличия уязвимости посмотрим на автоматически сгенерированный эксплойт, а также на условия, при которых эксплуатация ошибки будет успешной.
http://habrastorage.org/getpro/habr/post_images/e44/805/f16/e44805f16ce3f44b7ea31f819509fdce.png
Рис 1.2. Подробная информация о найденной XSS
Очевидно, что условие истинно только тогда, когда в запросе будет передан конкретный параметр:
textinputs[]='alert(1)'
Проверим, как это работает на практике. Отправляем на сервер эксплойт и получаем ответ:
http://habrastorage.org/getpro/habr/post_images/1a1/725/7ea/1a17257eae3b714fc26e6343882fe29e.png
Рис 1.3. Запрос и ответ сервера
Как видим, ответ сервера в HTML-странице содержит именно тот JavaScript-код, который мы отправляли в эксплойте.
Итак, мы убедились, что уязвимость существует. Самое время покопаться в коде и найти ошибку программиста. Воспользуемся информацией из Application Inspector, а именно — полным именем скрипта, номером строки и самим кодом, содержащим уязвимость (см. рис. 1.2).
Проанализировав исходный код, получаем такую картину:
Файл spellchecker.php:
17 строка: $textinputs = $_POST['textinputs'];
…
function print_textinputs_var() {
global $textinputs;
foreach( $textinputs as $key=>$val ) {
27 строка: echo "textinputs[$key] = decodeURIComponent(\"" . $val . "\");\n";
}
}
…
161 строка: print_textinputs_var();
Функция print_textinputs_var () объявлена в верхней части этого же скрипта и как раз содержит известную нам строку номер 27, в которой происходит вызов опасной функции “echo”:
Анализ показал, что код в строке 17 содержит недостаток — нефильтрованный параметр $_POST['textinputs'] — который и стал причиной уязвимости в строке 27. А это, в свою очередь, сделало XSS-атаку возможной.
Чего можно добиться с помощью XSS? Как минимум инвайта (http://habrahabr.ru/post/197466/) на Хабре А если звезды сойдутся — получить в свое распоряжение cookies администратора сайта, а следовательно, и доступ в админскую панель.
Уязвимость HTTP Response Splitting
В ходе дальнейшего сканирования была обнаружена возможность провести атаку, основанную на расщеплении HTTP-ответа сервера (HTTP Response Splitting):
http://habrastorage.org/getpro/habr/post_images/5ed/d17/072/5edd170724439788fe7d731da2c45c58.png
Рис 2.1. Отчет Application Inspector (справа — уязвимость в деталях)
Сгенерирован классический тестовый эксплойт, добавляющий дополнительный заголовок путем внедрения символов «перевод строки» и «возврат каретки». Эксплуатация возможна, если приложение работает на PHP версии ниже 5.1.2 (в более поздних версиях в интерпретатор встроена защита от таких атак).
http://habrastorage.org/getpro/habr/post_images/c30/c0b/a16/c30c0ba16f9c816a73d3d39b015f5f8a.png
Рис. 2.2. Граф потока выполнения демонстрирует наличие уязвимости
Результат анализа позволяет найти причину возникшей уязвимости и выработать рекомендации по ее устранению. Система PT AI указала, что вызов опасной функции произошел на 32-й строке файла set.php. Открыв исходный код, мы действительно видим, что в означенную строку попадает параметр, принимаемый без всякой фильтрации из POST-запроса в 15-й строке того же файла.
http://habrastorage.org/getpro/habr/post_images/26c/65f/348/26c65f348a771c82f191c27ee2238419.png
Рис 2.3. Программный код, содержащий уязвимость
Бывают случаи, когда разбор причин возникновения уязвимости является значительно более трудоемким, однако в данном случае и причины возникновения уязвимости, и пути ее устранения очевидны. Программисту необходимо добавить дополнительные проверки при присвоении значения переменной $back.
Уязвимость Open Redirect
В результате сканирования была обнаружена возможность провести атаку, классифицируемую как Open Redirect — открытое перенаправление:
http://habrastorage.org/getpro/habr/post_images/6a9/7f9/71a/6a97f971a7425b2e1631a2dbce95a04a.png
Рис 3.1. Отчет о наличии Open Redirect, с подробной информацией
Воспользуемся автоматически сгенерированным запросом-эксплойтом: отправим его на сервер-стенд и проанализируем ответ.
http://habrastorage.org/getpro/habr/post_images/862/354/e19/862354e19a9691d73dba930f72370a4b.png
Рис 3.2. Запрос-эксплойт для проверки уязвимости Open Redirect и ответ на него
Как мы видим, в исследуемой CMS действительно имеет место открытое перенаправление: ответом на запрос стала страница стороннего ресурса, переданная в векторе атаки. Попробуем разобраться в причинах. Отчет говорит о том, что точкой выхода атаки является строка 32 файла set.php. Откроем программный код:
http://habrastorage.org/getpro/habr/post_images/aba/2eb/634/aba2eb6348e9b08ccc0abd48e5634198.png
Рис 3.3. Уязвимый участок программного кода
В 32-й строке формируется заголовок location со значением из переменной $back. В свою очередь, переменная $back принимает свое значение из массива $_POST в 15-й строке того же файла без всяких дополнительных проверок. Таким образом становится ясна причина уязвимости — передача нефильтрованного параметра в 15-й строке файла set.php. Для устранения ошибки необходимы дополнительные проверки для переменной $back.
Чем опасна эта уязвимость? Прежде всего — возможностью практически незаметно для пользователя перенаправить его на зараженную страницу, а затем, так же незаметно, вернуть обратно.
Сплитинг и редирект в свежей PHP и Internet Explorer
Сплитинг с использованием последовательности символов %0D%0A работает на версиях PHP ниже 5.1.2, однако в некоторых ситуациях он возможен, даже если на сервере используется современная версия PHP.
Подходящие условия возникают, если клиентом является браузер Internet Explorer: он понимает последовательности %0A%20 или %0D%0A%20 как разделитель, а другие браузеры считают новую строку, начинающуюся с пробела, продолжением предыдущего заголовка. Такое поведение IE и недостаточная фильтрация в функции header() в PHP делают сплитинг возможным. Баг в header() исправлен недавно (bugs.php.net/bug.php?id=68978 (http://bugs.php.net/bug.php?id=68978)) и скоро попадет в релизы.
Примеры внедрения заголовка и содержимого в IE — ниже, адрес для проверки: molnar.es/php-header/test.php.
http://habrastorage.org/getpro/habr/post_images/c5b/bf4/72d/c5bbf472dfd5fcfcdbf01391c4ca325f.png
Рис. 4.1
http://habrastorage.org/getpro/habr/post_images/f70/c52/070/f70c52070f2895230e4eb710b99f3a48.png
Рис. 4.2
Проверить внедрение заголовков и открытое перенаправление на уязвимом сценарии (InstantCMS set.php в IE) можно и с помощью AI. Возьмем информацию из двух эксплойтов, полученных AI (адрес, метод, нефильтруемый параметр) для демонстрации такого вектора атаки на примере ptsecurity.com. Сделаем форму, которая посылает нужный вектор на нужный адрес, и посмотрим, работает ли атака. Как видим, да: на рис. 4.4 видно и адрес скрипта (set.php), и редирект (302-й статус и потом загрузку ptsecurity.com) и сплитинг (заголовок custom header).
Теперь по шагам:
1. Создаем страницу с формой:
http://www.ptsecurity.com/
Custom-Header: Test
2. Заходим на страницу в IE и отправляем запрос.
Результат выполнения запроса:
http://habrastorage.org/getpro/habr/post_images/9be/a84/125/9bea84125bcd008bd057d2007dcb4167.png
Рис. 4.3
http://habrastorage.org/getpro/habr/post_images/fa9/007/d1a/fa9007d1a833e9fbe4376c72993238d6.png
Рис. 4.4
На рис. 4.4 видно, что помимо перенаправления был установлен заголовок Custom-Header со значением Test.
SQL Injection
Рассмотрим еще один пример уязвимости, обнаруженной при помощи AI. Согласно результатам сканирования, в InstantCMS возможно внедрение SQL-кода (SQL Injection), да еще и в различных вариантах.
http://habrastorage.org/getpro/habr/post_images/faf/c56/bb5/fafc56bb539843ecd74adccc7bfec3ed.png
Рис. 5.1. Фрагмент отчета PT AI. Однотипные SQL-инъекции — и подробная информация об одной из них
Помимо определения уязвимого фрагмента кода и родительской уязвимости в приложении, PT AI выдает необходимые условия для проведения атаки.
На рис. 5.1 видно, что для эксплуатации SQL Injection требуются несколько условий, одно из которых — наличие в сессии вектора атаки. Это признак межмодульных уязвимостей (Second Order SQL Injection, хранимых XSS). У таких багов данные попадают в уязвимую функцию не сразу из переменных от точек входа, а из каких-то промежуточных хранилищ — базы, сессий и т. п., где они до этого каким-то образом оказались.
Эксплуатация межмодульных уязвимостей происходит в несколько этапов. Например, для хранимой XSS данные одним запросом заносятся в СУБД, а вторым запросом — извлекаются оттуда и чем-то выводятся на страницу.
http://habrastorage.org/getpro/habr/post_images/1ad/f65/9c9/1adf659c9bcb42b6100ac7d52aaa19c5.png
Рис. 5.2. Схема эксплуатации хранимых XSS
Продемонстрируем эксплуатацию найденной уязвимости Second Order SQL Injection в условиях, которые позволяют злоумышленнику изменять значения переменных в сессии. Возьмем простейший пример — виртуальный хостинг с общим хранилищем сессий. У хостинга есть ошибка конфигурации — значение директивы PHP session.save_path, которое по умолчанию равно /tmp (подробности (http://php.net/manual/en/session.configuration.php#ini.session.save-path)).
Если на сервере крутятся несколько сайтов, один из которых подконтролен злоумышленнику, мы можем атаковать соседний ресурс, функционирующий на базе InstantCMS, обладая минимальными правами.
Для этого необходимо:
1. Создать файл сессий с вектором для SQL Injection.
2. Сделать запрос с cookie, соответствующим файлу сессии из п. 1, к странице InstantCMS, при генерации которой вектор из сессии попадет в SQL-запрос.
Пример PHP-скрипта, генерирующего файл:
' . $output . '';
?>
Атака проходит в два этапа:
Сначала запускается скрипт, который создает файл с вектором и выводит значение для cookie сессии.
http://habrastorage.org/getpro/habr/post_images/d4e/9fb/4a9/d4e9fb4a9cfab48033cd657168be6e34.png
Рис. 5.3. Пример файла с вектором для SQL Injection в InstantCMS
Затем отправляется следующий запрос на сайт с InstantCMS:
GET /admin/index.php HTTP/1.1
Host: victim
Cookie: PHPSESSID=session
Connection: close
Ответ сервера будет получен примерно через 5 секунд для вектора с sleep(5), что подтвердит наличие SQL Injection.
Стоит подчеркнуть еще пару моментов:
Описанный сценарий атаки не сработал бы в случае, если бы в коде InstantCMS разработчики устанавливали значение session.save_path, которое бы отличалось от значения для сайта атакующего, и права на директорию с сессиями не давали получать список файлов, читать, изменять их и создавать свои.
Иногда встречаются баги с инъекцией в сессию (1 (http://www.php-security.org/MOPB/PMOPB-46-2007.html), 2 (http://www.php-security.org/2010/05/31/mops-2010-060-php-session-serializer-session-data-injection-vulnerability/index.html)) — как в самом PHP, так и в коде приложений.
Уязвимость SQL Injection позволяет провернуть множество нехороших фокусов, от чтения содержимого таблиц БД до заливки на сервер веб-шелла, это наиболее опасный вид атаки среди рассмотренных в данной статье. Об ошибках управления сессиями можно почитать в презентации (http://2013.zeronights.ru/includes/docs/Andrey_Danaw_-_Session_management_errors_in_cloud_solutions_and_ in_classic_hosting_systems.pdf) на ZeroNights, где показывали похожий случай ошибки управления сессиями применительно к CMS.
На этом с InstantCMS — все. Исследование уязвимостей в других системах с открытым кодом мы продолжим в следующих материалах.
Источник: http://habrahabr.ru/company/pt/blog/250675/