Способ расширения XSS payload-а

Забавно расширял XSS payload в Moodle. XSS росла из поля с Skype идентификатором(CVE-2013-4341) и была ограничена 50 символами минус нагрузка на спец символы.

Поэтому был выбран следующий подход:
1) Исполняем код из title(имя и фамилия)
" onerror='eval(document.title.substr(1,20)'>

2) В title держим код, который eval содержимое description поля

3) В description держим полезную нагрузку и код ответственный за конспирацию(возвращение в нормальное состояние полей и title)

А еще там была CSRF и можно было устроить Sammy-2 =)

Коротко об уязвимостях браузерных игр

Когда видишь игру, всегда хочется выиграть. Особенно если это еще какая нибудь промо-акция, то руки так и чешутся. А если попытаться выиграть изнутри?

Была такая игра от РЖД(сделанная за миллионы рублей): надо было вагоны отмывать от граффити. Игра на Flash и все взаимодействие с сервером заключалось в отправке количества очков, времени игры, аккаунта в VK и чего то еще HTTP методом на сервак. Подменой параметров можно было переместиться на первую строчку. Это первое на что я смотрю при анализе игр:
- какое взаимодействие с сервером
- в каком виде уходят параметры
- что они значат
Добавь они шифрование\проверочную сумму и они отсекут большую часть исследователей, мало кому хочется копаться в swf и искать ключ\алгоритм.

Как еще они могут защититься? Например добавить дополнительное взаимодействие с игрой:
- выход на следующий раунд
- приобретение дополнительных опций
- контроль времени начала и промежуточные точек
Это конечно усложнит игру и приведет к большей нагрузке на сервер, но опять таки отсечет большую часть читеров. Вот неплохая статья по защите просто игра на хабре.

Второй момент на который стоит глянуть, так это возможность изменения переменных в программе. Скачиваем какой нибудь Cheat Engine. Выбираем нужный нам процесс, интересную нам переменную и ищем, ищем, модифицируем.
Как можно защититься:
- избыточное хранение важных переменных
- шифрование важных переменных
- все это вкупе с обфускацией кода
Опять таки, таким образом мы откинем большую часть исследователей.

Как добиться наибольшей стойкости? Перенести всю игровую механику на серверную сторону, за клиентом оставить только отображение. Но такой подход возможен только для игр без большого экшена. Такой способ оставляет только одну возможность для читеров -- написание AI для игры. Это не всегда возможно. И тут можно добавить дополнительные проверки: человеческое поведение, тесты Тьюринга.

Какие интересные кейсы взлома браузерных игр были у вас?

Итог нескольких пентестов

Вот несколько интересных итогов после нескольких пентестов:

1) Частый сценарий не пометка капчи пройденной для сессии после ее фактического прохождения. Грешат все поголовно.
2) Начал писать свой SqlMap, слил им 2 базы, вовремя остановился писать.

3) Дописал и начал использовать data-receiver. Правда большинство спасают дефолтные настройки http_only для сессии.
4) Наблюдал зоопарк шеллов и мэилеров на одном из ресурсов.
5) Наблюдал шаланды полные кефали открытых паролей и не соленных хэшей. Меняю все пароли и включаю двухфакторку.
6) Нашел неописанный нигде эксплоит для старого или некорректно настроенного плагина(как в моем случае) для tinyMCE. Может его все таки опубликуют на Exploit DB.

# Exploit Title: MCFileManager Plugin for TinyMCE 3.0.9.2 zip archive upload vulnerability# Google Dork: inurl:/tiny_mce/plugins/filemanager/# Date: 04.11.2015# Exploit Author: Artem Bachevsky# Contact: fryday [dot] kg [at] gmail [dot] com# Vendor Homepage: http://www.tinymce.com/develop/changelog/?type=phpmcfilemanager
# Version: applicable to <= 3.0.9.2 or with misconfigured higher versions

I found a vulnerability in TinyMCE filemanager plugin. It allows to upload executable code(e.g. php file) to server. You can exploit it like that: 1. zip your shell file 2. upload your zip file(filemanager allows to upload zip) 3. unzip your archive 4. PROFIT

Certainly there should be some errors in server settings to expoit it. In higher versions exploit possible with incorrect plugin configuration.

Оставлю и тут. Мое прощение за мой английский, ну и за русский тоже %)
Залил с помощью него шелл. Дальше ничего интересного =)

7) Стал добавлять в рекомендации: правильно настраивать robots.txt, иначе энтропия падает.

8) Видел "интересные" решения с плейсхолдерами в виде названий переменных, которые задаются в админке. Оригинальный способ для раскрытия инфы.

Эти неприятные upload-ы

Всем конечно известно, что нельзя давать загружать пользователю исполняемые скрипты(php, shtml итд) к себе на сайт, а если это требуется то запрещать исполнение в папке их хранения. Но не все это соблюдают.

Ребята, сайт которых я просматривал позволяли загружать к себе что хочешь. Правда *.php до места не догружалось, а все остальное не умело исполняться.

Выручил в этой ситуации html файл + и не проставленный флаг http only для куки сессии. Файлы по умолчанию открываются в браузере и в текущем домене. Загружаем страничку с примером кода с data-receiver. В итоге доступ к пользователю с привилегиями!

Как обезопасится:
1) http only флаг для кук сессии
2) к линкам на прикрепленные файлы добавлять атрибут download.
Например:
 <a href='foo.html' download>link</a>
3) А для не обладателей HTML5 совместимых браузеров и рукастых пользователей(ведь всегда можно скопировать URL и открыть в новом табе) следует добавлять следующий хедер Content-Disposition: attachment;
Это вроде можно настроить в .htaccess для папок с загруженными файлами.

Опять таки меры 2 и 3 можно применить только для некоторых расширений файлов.

[update]
Вот рекомендации OWASP поэтому поводу
https://www.owasp.org/index.php/Unrestricted_File_Upload