https://course.secsem.ru/w/index.php?title=%D0%92%D0%B5%D0%B1-%D0%B1%D0%B5%D0%B7%D0%BE%D0%BF%D0%B0%D1%81%D0%BD%D0%BE%D1%81%D1%82%D1%8C/%D0%90%D1%82%D0%B0%D0%BA%D0%B8_SSRF&feed=atom&action=historyВеб-безопасность/Атаки SSRF - История изменений2024-03-28T14:43:02ZИстория изменений этой страницы в викиMediaWiki 1.32.0https://course.secsem.ru/w/index.php?title=%D0%92%D0%B5%D0%B1-%D0%B1%D0%B5%D0%B7%D0%BE%D0%BF%D0%B0%D1%81%D0%BD%D0%BE%D1%81%D1%82%D1%8C/%D0%90%D1%82%D0%B0%D0%BA%D0%B8_SSRF&diff=332&oldid=prevLgeek19: Новая страница: «=Микросервисная архитектура= Архитектурный стиль микросервисов — это подход, при котор…»2020-10-27T09:44:15Z<p>Новая страница: «=Микросервисная архитектура= Архитектурный стиль микросервисов — это подход, при котор…»</p>
<p><b>Новая страница</b></p><div>=Микросервисная архитектура=<br />
Архитектурный стиль микросервисов — это подход, при котором единое приложение строится как набор небольших сервисов, каждый из которых работает в собственном процессе и коммуницирует с остальными используя легковесные механизмы, как правило HTTP. Сами по себе эти сервисы могут быть написаны на разных языках и использовать разные технологии хранения данных. Такой подход противопоставляется монолитному стилю, при котором вся логика по обработке запросов выполняется в единственном процессе.<br />
[[Файл:Mono-micro.png]]<br />
<br />
При построении приложения с микросервисной архитектурой недостаточно установить защиту только на входе.<br />
[[Файл:Micro-1.png|500px]]<br />
[[Файл:Micro-2.png|500px]]<br />
<br />
При разработке ставятся следующие задачи:<br />
* взаимная аутентификация микросервисов;<br />
* авторизация запросов к микросервисам;<br />
* защищенный транспорт.<br />
<br />
==Аутентификация и авторизация==<br />
'''Аутентификация''' - процедура проверки подлинности пользователя.<br />
<br />
'''Авторизация''' - процедура проверки наличия прав на действие.<br />
<br />
=Схемы=<br />
<br />
Существует следующая традиционная схема URL:<br />
<pre><br />
<схема>:[//[<логин>[:<пароль>]@]<хост>[:<порт>]][/<URL‐путь>][?<параметры>][#<якорь>]<br />
</pre><br />
<br />
В этой записи:<br />
* схема - схема обращения к ресурсу; в большинстве случаев имеется в виду сетевой протокол;<br />
* логин - имя пользователя, используемое для доступа к ресурсу;<br />
* пароль - пароль указанного пользователя;<br />
* хост - полностью прописанное доменное имя хоста в системе DNS или IP-адрес хоста;<br />
* порт - порт хоста для подключения;<br />
* URL-путь - уточняющая информация о месте нахождения ресурса; зависит от протокола;<br />
* параметры - строка запроса с передаваемыми на сервер (методом GET) параметрами. Начинается с символа ?, разделитель параметров — знак &;<br />
* якорь - строка, которая относится к ресурсу, который подчинен другому первичному ресурсу; пример: https://course.secsem.ru/wiki/Веб-безопасность/Введение_в_веб-технологии#Ip.<br />
<br />
Кроме стандартной схемы HTTP/HTTPS существуют следующие стандартные протоколы.<br />
* схема GOPHER - сетевой протокол распределённого поиска и передачи документов;<br />
* схема TFTP - используется главным образом для первоначальной загрузки бездисковых рабочих станций (ПК без несъёмных средств для долговременного хранения);<br />
* схема File - потенциальное обращение к диску;<br />
* схема FTP, SFTP, LDAP и т.д.<br />
<br />
=SSRF=<br />
Атака SSRF - Server Side Request Forgery - возможна в случае наличия уязвимости ПО, позволяющей злоумышленнику спровоцировать сервер на отправку запроса на произвольный адрес.<br />
Рассмотрим веб-чат, который позволяет прикреплять к сообщениям картинки-карточки, добавляя ее URL. Причем карточки формируются на бекенде.<br />
Предполагается, что при загрузке карточки приложение будет обращаться по указанному URL и формировать карточку.<br />
[[Файл:Chat-1.png|700px]]<br />
<br />
Но злоумышленник может предоставить в качестве URL картинки некий внутренний адрес, таким образом получив несанкционированный доступ к сканированию внутренней сети компании и отправке HTTP-запросов во внутреннюю сеть (где микросервисная архитектура).<br />
[[Файл:Chat-2.png|700px]]<br />
<br />
==Payloads==<br />
Рассмотрим некоторые полезные нагрузки которые могут быть использованы при SSRF.<br />
* '''произвольные HTTP GET запросы с отображением ответа'''<br />
** localhost;<br />
** внутренние ресурсы:<br />
*** Gitlab;<br />
*** Redmine;<br />
*** Jenkins и т.п.<br />
* '''произвольные HTTP GET запросы «слепой случай»'''<br />
** код ошибки;<br />
** время отклика.<br />
* если удастся перехватить запрос, то в нем могут быть полезны<br />
** user-agent - стек технологий;<br />
** дополнительные заголовки при взаимодействии микросервисов;<br />
** cookie или JW token - при большом везении.<br />
* '''прочее'''<br />
** MySQL (Port-3306);<br />
** FastCGI(Port-9000);<br />
** WSGI (Port-9000);<br />
** Memcached (Port-11211);<br />
** Redis (Port-6379);<br />
** Zabbix (Port-10050);<br />
** SMTP (Port-25)<br />
<br />
==Пример==<br />
Рассмотрим приложение, код которого расположен ниже.<br />
<syntaxhighlight lang="PHP"><br />
<?php<br />
<br />
/**<br />
* Check if the 'url' GET variable is set<br />
* Example - http://localhost/?url=http://testphp.vulnweb.com/images/logo.gif<br />
*/<br />
if (isset($_GET['url'])){<br />
$url = $_GET['url'];<br />
<br />
/**<br />
* Send a request vulnerable to SSRF since<br />
* no validation is being done on $url<br />
* before sending the request<br />
*/<br />
$image = fopen($url, 'rb');<br />
<br />
/**<br />
* Send the correct response headers<br />
*/<br />
header("Content-Type: image/png");<br />
<br />
/**<br />
* Dump the contents of the image<br />
*/<br />
fpassthru($image);}<br />
</syntaxhighlight><br />
Злоумышленник имеет полный контроль над параметром URL, он может делать произвольные запросы к любому веб-сайту и к ресурсам на сервере. Рассмотрим несколько примеров запросов.<br />
Запрос к Apache HTTP Servers жертвы.<br />
<pre><br />
GET /?url=http://localhost/server-status HTTP/1.1<br />
Host: example.com<br />
</pre><br />
Атакующий может получить доступ к внутренним сервисам, например матаданным экземпляра облачной службы.<br />
<pre><br />
GET /?url=http://169.254.169.254/latest/meta-data/ HTTP/1.1<br />
Host: example.com<br />
</pre><br />
Кроме того атакующий может обратиться к нестандартной схеме.<br />
<pre><br />
GET /?url=file:///etc/passwd HTTP/1.1<br />
Host: example.com<br />
</pre><br />
При использовании приложением curl, то атакующий может использовать схему URL dict: // для отправки запросов любому хосту на любом порту и отправки пользовательских данных.<br />
<pre><br />
GET /?url=dict://localhost:11211/stat HTTP/1.1<br />
Host: example.com<br />
</pre><br />
==Обход фильтрации==<br />
В качестве простых средств защиты можно проверять схему в ссылке и работать только с HTTP/HTTPS и также проверять адрес в ссылке и блокировать запросы на внутренние подсети (192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8, 127.0.0.0/8...) Но этого недостаточно, есть различные способы обхода подобной фильтрации.<br />
===Собственные DNS записи===<br />
Возможно создавать собственные DNS записи, указывающие на локальные адреса.<br />
[[Файл:Localtest.png]]<br />
===DNS rebinding===<br />
Основная идея DNS rebinding - обмануть SOP. Алгоритм:<br />
# регистрация домена (attacker.com) + контроль над DNS-сервером<br />
## ответы имеют короткое время жизни<br />
## предотвращение кэширования<br />
# жертва переходит на вредоносный домен<br />
## DNS-сервер возвращает настоящий IP сервера с вредоносным кодом (JS)<br />
# вредоносный скрипт исполняется<br />
# новый запрос DNS для данного домена<br />
## ответ: attacker.com находится на новом IP (напр. внутренний)<br />
# получен доступ к внутренней структуре (SOP)<br />
===Перенаправление===<br />
Создание внешнего ресурса, цель которого - перенаправить на внутренний ресурс. Возможно изменение схемы. <br />
Запрос:<br />
<pre><br />
https://hackers-normal-site.com<br />
</pre><br />
Ответ:<br />
<pre><br />
HTTP/1.1 302 Found<br />
Date: Fri, 24 Aug 2018 12:15:36 GMT<br />
Location:<br />
http://169.254.169.254/<br />
</pre><br />
===Альтернативные представления===<br />
* многие библиотеки поддерживают сокращения: 127.0.0.1 и 127.1 для них – одно и то же;<br />
* многие библиотеки поддерживают отличные от десятичного представления октетов: 127.0.0.1 и 0177.1 для них – одно и то же;<br />
* многие библиотеки поддерживают смешанные представления октетов: 127.127.0.1 и 0x7f.0177.1 для них – одно и то же;<br />
* например, для cURL нет разницы между 127.0.0.1 и 127.1, и 0177.1, и 0x7f.1, и 2130706433.<br />
===IPv6===<br />
Не стоит забывать про Ipv6. Возможно он поддерживается и тогда<br />
<pre><br />
127.0.0.1 == 0:0:0:0:0:0:0:1 == [::1]<br />
</pre><br />
===Неоднозначные URL===<br />
Использование разных стеков технологий может привести к разночтению URL защитой и бекендом.<br />
[[Файл:Ambiguous-URL.png]]<br />
==Защита==<br />
Для уменьшения опасности SSRF стоит:<br />
* ограничить доступ к внутренней инфраструктуре для потенциально подверженных SSRF серверов:<br />
** ввести межсервисную аутентификацию;<br />
** использовать внешний прокси;<br />
* ограничить поддерживаемые схемы;<br />
* отключить поддержку перенаправлений или проверять каждый шаг;<br />
* валидировать доменные имена;<br />
* разобраться как используемая библиотека обрабатывает адреса.<br />
=Ссылки=<br />
* [https://drive.google.com/file/d/1FrWf8Penp85zmGdOSq7H3m_nqgd9L_zB/view?usp=sharing Презентация]<br />
* [https://yadi.sk/d/o4cFtxls-WlUAw?w=1 Видео]<br />
* [https://docs.google.com/document/d/1v1TkWZtrhzRLy0bYXBcdLUedXGb9njTNIJXa3u9akHM/edit SSRF Bible]</div>Lgeek19