El Scripto

Хола, комрадос! Сегодня расскажу вам о тулзе, которая очень поможет при проведении XSS-атак.

Будучи ленивым, как стереотипный мексиканец, пишу о ней только сейчас, хотя непосредственный автор ее описал еще три года назад в ксакепе.

Называется она на испанский манер - El Scripto (мне кажется об этом вы уже догадались). Простыми словами, это такой кастрированный BeEF или наоборот, веб-сниффер на стероидах. Если нужны детали - отсылаю вас к вышеупомянутой статье.

Я некоторое время использовал el scripto для своих нужд (кошмарил панельки ботов и прочие диавольские поделки), а потом почему-то вздумал проверить, насколько защищен скрипт для XSS-атак от XSS-атак.

Погнали, начнем с веселого и бесполезного.

Незначительные ошибки, требующие суицидальных наклонностей от эксплуатирующего

1. Заливка шелла при установке. Скрипт инсталляции содержит вот такие замечательные строки:

Фильтрации никакой нет, а это значит, что мы можем оставить бекдорчик на этапе инсталляции:

А потом его использовать:

2. Хранимая XSS в логине администратора. По той же причине, по которой мы можем залить бекдор, мы можем внедрить и наркоманскую XSS. Например, взяв модный и по настоящему хацкерский логин:

С каждым переходом по страницам админки, нас будет встречать победоносный алерт:

3. Self-RCE. Мы можем внедрить произвольный python-код (не спрашивайте зачем, можем и все) в скачиваемый из админки плагин Burp'а:

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

4. Хранимая XSS в js-коде эксплоита. Если мы попробуем создать новый эксплоит, на основе существующего шаблона, то можем легко и просто выстрелить себе в голову:

Ну и результат:

А можно сделать по другому (выстрел уже в ногу):

Тогда xss отработает только при переходе по линку jquery.min.js?ver=N:

Второй вариант можно вылечить, добавив заголовок Content-type:text/plain.

5. Хранимая XSS в названии эксплоита. Если мы выберем какое-то небанальное название для эксплоита, типа такого:

Нас ждет xss на главной странице:

6. Хранимая XSS через название файла эксплоита. Файл prepare.html:

Переменная $files[$i] никак не фильтруется, что означает, что если мы назовем наш файл с эксплоитом как-то витеивато(трюк пройдет только на *nix), например:

И положим его в папку exploits (да, нужен доступ к файлам, не спрашивайте, зачем нам это делать), то сможем увидеть, как в нашем XSS-фреймворке отрабатывает внедренная в него XSS, которая использует код нашего XSS-фреймворка:

С помощью своего богатого воображения, представьте на этом месте картиночку с фрактальным XSSzibit'ом.

На этом глупости закончились.

Одна действительно интересная ошибка.

7. Хранимая XSS через отправку репорта.
Посмотрим код reports.html:

Вроде бы все значения обрабатываются htmlspecialchars(), а в те, что не обрабатываются не внедрить html-код. Все, кроме линка на скриншоты:

И получаем XSS прямо на странице репортов:

Достаточно иронично, что фрейморк для XSS сам содержит XSS.
Не думаете?