2018 год уже на пороге.
Но большинство бородатых уязвимостей продолжают жить в развитых системах.
И несмотря на то, что он появился Топ-10 OWASP 2017 г.
.
И приоритет некоторых вещей сильно изменился.
Как и прежде, ничто не мешает вам наткнуться на ситуации, актуальные в 2010 .
История началась с простого любопытства по поводу продукции компании, где работает мой друг.
Товар интересный.
Покупают этот товар очень обдуманно и по ценникам с 6 цифрами.
У этой компании нет официального вознаграждения за обнаружение ошибок.
Но я подумал, что даже если что-то найду, то через друга разберусь и передам.
Найти основной продукт компании не составило труда.
Есть официальный сайт с демо-приложением.
Я зашёл туда посмотреть, что там, попутно превращая весь трафик через прокси в Костюм отрыжки .
Когда я увидел поле ввода, мне сразу захотелось туда вставить xss. Застрял банальный вектор
И что, по вашему мнению, произошло? Конечно, это сработало!<script>alert(xss);</script>
Я искал другие возможные поля ввода информации, и моя XSS-атака осуществлялась абсолютно везде.
Нет, я лгу! Почему-то в одном месте не получилось.
Но, потратив немного времени, мне удалось победить его другим вектором полезной нагрузки и обходом экранирования.
Итак, на руках имеется как минимум 8 векторов xss. Можно было многократно увеличить это число, но тратить время на обход функционала системы было очень лень.
И было ясно, что проблема сложная.
Я уже хотел пойти поискать через друга виновных в этом безобразии.
Но я подумал, что если с экранированием все так плохо, то, возможно, есть что-то еще.
Я отложил возможный контакт на потом и пошел еще раз посмотреть.
В журналах были намеки на то, что приложение подозревается в возможности реализации CSRF-атаки.
То есть не было CSRF-токенов, предотвращающих возможность такой атаки.
Чтобы подтвердить мои опасения, мне нужен был реальный пример.
И для того, чтобы мои комментарии были восприняты максимально ответственно, мне нужен был пример, показывающий максимальный ущерб системе.
Несколько слов о CSRF, хотя можно было бы и погуглить Этот .
Представьте, что вы вошли в веб-клиент вашего банка.
А потом вам присылают ссылку на «смешных котиков» в ВКонтакте.
Вы отложили номер карты родственника, которому только что хотели перевести деньги, и пошли смотреть котов.
Кошки были очень забавными.
И тут вы решили перевести деньги своему родственнику.
Вернувшись на следующую вкладку веб-клиента банка, вы пытаетесь осуществить перевод, но денег вам уже не хватает. И вы никогда в жизни не догадаетесь, что на ваш банковский счет совершили набег коты-бандиты.
Эти коты притворялись забавными, пока их родственники переводили деньги с вашего счета продавцам кошачьего корма и валерьянки.
Это неуклюжий пример.
И, конечно, ни в одном банке это будет возможно.
Но этот пример должен помочь вам понять серьезность уязвимости CSRF. А теперь без котиков и с подробностями.
В исследуемом приложении есть простая возможность выхода из системы.
Вы можете проверить выход пользователя из системы через csrf. Вы скажете: что тут такого, это же не опасно! Но это не вектор атаки.
Это всего лишь проверка нашей теории о том, что наша идея работает. Для этого нам нужно было создать в нашей подсети тестовый сайт со следующим контентом.
<html>
<body>
<form action=" https://example.com/client/api/logout ">
<input type="submit" value="Submit request" />
</form>
</body>
</html>
Далее авторизуйтесь с другого браузера.
Открываем в этом браузере тестируемое приложение с активной сессией входа в систему, а во второй вкладке наш сайт. Нажмите на нашу кнопку «Отправить».
Вернувшись на предыдущую вкладку с нашим тестовым приложением, мы обнаружим, что мы больше не авторизованы.
Поскольку наш пример сработал, вероятность того, что он сработает и в других местах, составляет 80%.
20% я оставил на то, что разработчики в важных местах используют защиту от CSRF-атак.
Но это случается редко.
Токены CSRF либо есть повсюду, либо их вообще не существует. Поскольку наш демо-сайт с приложением позволял войти в систему как системный администратор, я мог видеть, что может делать администратор, а главное, как он это делает. Интересным открытием стал сброс пароля пользователя системы.
Он выглядел примерно так <method="POST">
<input name="Id" value="1" />
<input name="newPassword" value="testerok" />
<input name="confirmPassword" value="testerok" />
И если вас не смутило то, что для смены пароля не нужно вводить старый пароль, то вас точно должно смутить то, что пользователи передаются по ID. И тогда сценарий атаки примерно следующий:
- Отправляем администратору сообщение в системе со ссылкой на нашу страницу.
- На нашей странице мы размещаем CSRF-код для смены пароля пользователя.
- Администратор переходит по ссылке.
- Пароль пользователя был изменен.
В этом случае администратор даже не поймет, что что-то произошло.
<html>
<body>
<form action=" http://example.ru/main/Security/Users/ChangePassword " method="POST">
<input type="hidden" name="Id" value="5" />
<input type="hidden" name="newPassword" value="test3" />
<input type="hidden" name="confirmPassword" value="test3" />
<input type="submit" value="Submit request" />
</form>
</body>
</html>
Нам остаётся только войти в систему под пользователем, которому администратор «случайно» установил новый пароль.
Тот же пример применим и в случае создания нового пользователя в системе.
Вы все равно можете сделать это тайно и создать суперпользователя! Под которым можно сидеть в системе и сливать кучу ценной информации о компании - заказы, документы, финансовую информацию.
Отдельно во всей этой истории хотелось бы выделить реакцию на проблемы.
И скорость их исправления.
На сообщения о XSS отреагировали довольно быстро.
К ним вообще вопросов не было.
Но с CSRF я начал получать следующие вопросы и возражения от ответственного лица.
Посмотрим, что скажут разработчики.По идее наша сессия привязана к IP и одного токена должно быть недостаточно (с) Руководитель отдела тестирования
Неужели только мой глаз дернулся в тот момент? О какой защите через белый список IP может идти речь, если администратор все делает со своего компьютера.
Это функция CSRF. Но это еще не все.
Ответственное лицо заявило следующее.
Ошибка №7 Пока не понимаю, как это реализовать (с) Руководитель отдела тестированияРечь идет о массовой смене паролей всех пользователей системы.
Тут мне пришлось напрямую прийти со скриншотами и рассказать, почему вообще нельзя оставлять эту опцию.
Вы можете перебирать все идентификаторы одновременно 
Ну и остановимся на тех, которые нам не интересны 
И, честно говоря, было грустно получать уточняющие вопросы по поводу столь очевидных и известных уязвимостей.
После всей переписки, разъяснений и уймы потраченного времени меня уведомили, что мне будет выплачено вознаграждение в рамках специального bug bounty специально для меня.
При этом расчет этого вознаграждения по сей день остается для меня своеобразным волшебством.
Хотя мне дали формулу, по которой все считали.
Все XSS, кроме одного, считались дубликатами и суммировались с коэффициентом уменьшения.
CSRF по другому коэффициенту.
В конце концов я получил 100 евро .
Но хорошо, что у меня вообще что-то получилось! Из-за «интересной» политики поддержки пользователей, большинство клиентов останутся без этих критических обновлений и исправлений.
Просто потому, что у этих клиентов нет годового пропуска на поддержку.
Так в какой-нибудь крупной компании, которая использует этот дорогой продукт, по сей день можно украсть куки или сделать что-то от имени пользователя, подсунув картинку с котиками.
Список клиентов впечатляет – банки, страховые, промышленные холдинги.
В каком-то смысле это оказался 0day (уязвимость, не имеющая исправления).
На мой взгляд, можно было бы поступить более мудро и благородно.
Microsoft все еще выпускает исправления для Windows XP. Я не раскрыл название компании и клиентов компании по морально-этическим соображениям.
Ну а представители беспокоятся о своей репутации.
График: 19 июля – сделаны доклады 9 августа — все отчеты подтверждены и награждены.
28 августа — исправлены проблемы с фильтрацией XSS. 14 ноября — реализовано исправление CSRF для клиентов, имеющих подписку на поддержку.
Теги: #тестирование #веб-сервисы #ecm #веб-сервисы для бизнеса #хакинг #информационная безопасность #Тестирование веб-сервисов
-
#02 - И Целого Байта Мало... | Крест Перемен
19 Oct, 24 -
Анти-Ie
19 Oct, 24 -
Личность Программиста
19 Oct, 24 -
Танцующая Беларуска Стала Звездой Youtube
19 Oct, 24
