Способ расширения 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 для игры. Это не всегда возможно. И тут можно добавить дополнительные проверки: человеческое поведение, тесты Тьюринга.

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

Разбор решений задачки о 24 монетах

С неделю назад я опубликовал в ФБ задачку, и получил ряд решений. Вот о них и расскажу.

Вот условие:

Есть 12 золотых и 12 серебряных монет. Одна из монет фальшивая (неизвестно, золотая или серебряная). Настоящие золотые монеты весят одинаково; настоящие серебряные тоже, но неизвестно, какие тяжелее (золотые или серебряные). Фальшивая золотая монета легче настоящих золотых, а фальшивая серебряная тяжелее серебряных. По виду можно сказать, золотая монета или серебряная, но нельзя сказать, настоящая или фальшивая. Сколько нужно взвешиваний, чтобы заведомо найти фальшивую монету?
Весы чашечные коромысла.

Использую вот эти оценки, находим нижнюю границу шагов: 3 шага. Неизвестно, как много сложностей добавляет дополнительные ограничения и новшества. Так, что если удастся за 3 шага, то это вин!

1) Я эту задачку решил так.

Монеты для шага 1: делим монеты на 3 кучки, в каждой по 4 золотых и серебряных. Взвешиваем любые две, назовем их кучка 1 и кучка 2.

Интерпретация взвешивания шага 1: если кучки равны, то фальшивка в третей кучке (4 золотых и 4 серебряных). Если не равны, то фальшивка либо в золотых монетах верхней чашки, либо в серебряных нижней чашки, то есть в этом случае мы можем сформировать кучку из 8 монет(4 золотых и 4 серебряных), где гарантированно будет фальшивка.

Монеты для шага 2: Берем нашу кучку с фальшивкой. Делим ее на три кучки: 2 золотых и серебряная,  2 золотых и серебряная и 2 серебряных. Взвешиваем кучку 1 и кучку 2.

Интерпретация взвешивания шага 2: если кучки равны, то фальшивка в третей кучке (2 серебряных). Если не равны, то фальшивка либо в золотых монетах верхней чашки, либо серебряная нижней чашки, то есть в этом случае мы можем сформировать кучку из 3 монет(2 золотых и серебряная), где гарантированно будет фальшивка.

Монеты для шага 3: если у нас после второго шага осталась кучка из двух серебряных, то все просто, просто будут две кучки по одной монете. Если у нас кучка из трех монет, (2 золотых и серебряная), то будем взвешивать по золотой монете, а серебряную отложим.

Интерпретация взвешивания шага 3: если взвешиваем серебро, то фальшивка в нижней чашке. Если взвешиваем золото и чашки равны, то фальшивка из серебра, иначе фальшивка в верхней чашке.

2) Сергей Фролов предложил следующий алгоритм:

Монеты для шага 1: делим монеты на 3 кучки, в каждой по 4 золотых и серебряных. Взвешиваем любые две, назовем их кучка 1 и кучка 2.

Интерпретация взвешивания шага 1: если кучки равны, то фальшивка в третей кучке (4 золотых и 4 серебряных). Если не равны, то фальшивка либо в золотых монетах верхней чашки, либо в серебряных нижней чашки, то есть в этом случае мы можем сформировать кучку из 8 монет(4 золотых и 4 серебряных), где гарантированно будет фальшивка.

Монеты для шага 2: Берем нашу кучку с фальшивкой. Делим ее на две кучки: 3 золотых и 3 серебряных и 1 золотая и серебряная. Также выделяем кучку из 3 золотых и 3 серебряных, которые заведомо настоящие. Взвешиваем кучку 1 и кучку 3.

Интерпретация взвешивания шага 2: если кучки равны, то фальшивка в второй кучке
(золотая и серебряная). Если не равны, то фальшивка либо в золотых монетах первой кучки, если чашка вверху, либо в серебряных первой кучки, если чашка внизу.

Монеты для шага 3: если у нас после второго шага осталась кучка из двух монет, то просто взвесим одну из монет с заведомо не фальшивой монетой того же материала. Если у нас кучка из трех монет, то будем взвешивать две монеты из этой кучки.

Интерпретация взвешивания шага 3: в первом случае, при равенстве чашек, то фальшивкой будет оставшиеся монета, при неравенстве, ее можно будет определить исходя из металла, который мы взвешивали. Во втором случае, если чашки равны, то фальшивкой будет оставшиеся монета, при неравенстве, ее можно будет определить исходя из металла, который мы взвешивали.

3) Способ предложил Руслан Батыров.

Поделим монеты на 12 кучек, по одной золотой и серебряной. Далее решаем задачу, следующим образом:


В качестве ответа мы получим, кучку и ее маркировку: Л или Т. Если Л, то фальшивка золотая, если Т, то серебряная.

4) Способ предложил Руслан Батыров.

Поделим монеты на 12 кучек, по одной золотой и серебряной. Теперь решаем задачу методом Дайсона.
В качестве ответа мы получим, кучку и ее маркировку: легкая или тяжелая. Если легкая, то фальшивка золотая, если тяжелая, то серебряная.
Дайсона, конечно метод универсальный, но понять идею лежащую за ним не легко. Насколько я понял, он не перекликается ни с одним вышеперечисленным методом.

Есть ли еще способы решить эту задачку? Какой из способов вам кажется наиболее понятным?

Котормочу бот!

Накидал тут быстренько бота для Telegram для перевода с кыргызского на русский или наоборот. Встречайте Котормочу(@kotormochubot)!!!

Реализация простейшая, переводы беру с http://tili.kg. Хотел использовать Google Translate API, но оказалось, что он полностью платный. Подсказывают, что можно посмотреть в сторону PhantomJS и таким образом использовать веб-версию переводчик...или может кто нибудь захочет проспонсировать API %)

А может быть tili.kg захочет похостить сервис и дать прямой API, а то на GAE маленькие квоты, а писать распределенный сервис и искать словарь немного лень %))

Кстати, исходники тут: https://github.com/frydaykg/kotormochu-bot
Может кто-то захочет что-то исправить или улучшить. Жду форков и пулл реквестов. Или хотя бы критики и пожеланий)

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

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

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