Как скомпрометировать систему документооборота в несколько кликов

в 12:51, , рубрики: ECM, веб-сервисы, веб-сервисы для бизнеса, взлом, информационная безопасность, тестирование, Тестирование веб-сервисов

На пороге уже стоит 2018 год. Но большинство бородатых уязвимостей продолжает жить в разрабатываемых системах. И не смотря на то что появился OWASP Top-10 2017. И приоритетность определенных вещей сильно поменялась. По прежнему ничего не мешает натыкаться на ситуации, которые были актуальны в 2010.

Как скомпрометировать систему документооборота в несколько кликов - 1

История началась с банального любопытства к продукту компании, в которой работает мой знакомый. Продукт интересный. Покупают данный продукт очень вдумчиво и за ценники с 6 знаками. Баг-баунти официальной у этой компании нет. Но я подумал, что даже если что-то найду — через знакомого разрулю и передам.

Найти основной продукт компании не составило труда. Есть официальный сайт с демо-приложением. Полез туда смотреть что там есть, попутно обернув весь трафик через прокси в Burp Suit.
Увидев input field, мне сразу же захотелось воткнуть туда xss. Воткнул банальный вектор

<script>alert(xss);</script> 

И что вы думаете произошло? Конечно, сработало!

Как скомпрометировать систему документооборота в несколько кликов - 2

Я поискал еще возможные поля ввода информации, и абсолютно везде выполнялась моя XSS атака. А нет, вру! В одном месте почему-то не сработало. Но, потратив немного времени, я его смог одолеть с другим payload вектором и обходом экранирования. Итак, на руках есть как минимум 8 xss векторов. Можно было это число увеличить в разы, но было очень лениво тратить время на обход функциональности системы. Да и видно было, что проблема комплексная.

Уже хотел пойти искать, через знакомого, ответственных за это безобразие. Но подумал, что если все так плохо с экранированием, то возможно есть еще что-то. Отложил возможный контакт на попозже и полез еще смотреть.
В логах были намеки подозревать приложение в возможности реализовать CSRF атаку. Т.е не было никаких CSRF токенов, которые предотвращают возможность подобной атаки. Чтобы подтвердить мои опасения, нужен был реальный пример. А чтобы к моим замечаниям отнеслись максимально ответственно, нужен был пример, который показывает максимальный урон системе.

Пару слов о CSRF, хоть вы и могли бы загуглить это.
Представьте что вы зашли в веб-клиент своего банка. И тут вам вконтактике присылают ссылочку на "смешных котиков". Вы отложили в сторону номер карты родственника, которому хотели только что перевести деньги, и пошли поглядеть на котиков. Котики были действительно смешные. И после вы решили все же перевести родственнику немного деньжат. Вернувшись в соседнюю вкладку веб-клиента банка, вы пытаетесь сделать перевод, но вот денег у вас уже недостаточно. И вы в жизни не догадаетесь, что обнесли ваш банковский аккаунт котики-бандиты. Эти котики прикидывались смешными, пока их сородичи переводили деньги вашего счета продавцам кошачьего корма и валерьянки.

Как скомпрометировать систему документооборота в несколько кликов - 3

Это топорный пример. И, безусловно, подобное ни в одном банке уже провернуть не получится. Но этот пример должен вам помочь понять всю серьезность уязвимости CSRF.

А теперь без котиков и с подробностями.

В исследуемом приложении есть простая возможность сделать logout. Можно проверить разлогинивание пользователей через csrf. Вы скажете: что тут такого, это не опасно! Но это и не вектор атаки. Это лишь проверка нашей теории о том, что наша идея работает.

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

<html> 
<body> 
<form action="https://example.com/client/api/logout"> 
<input type="submit" value="Submit request" /> 
</form> 
</body> 
</html>

Дальше выполняем вход в систему с другого браузера. Открываем в этом браузере тестируемое приложение с активной логин-сессией, а во второй вкладке наш сайтик. Нажимаем на нашу кнопку submit. Вернувшись в предыдущую вкладку с нашим тестовы приложением, мы обнаружим, что уже не залогинены.

Раз наш пример сработал, значит с вероятность 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 привязана, и одного токена должно быть мало (с) Руководитель отдела тестирования

Как скомпрометировать систему документооборота в несколько кликов - 4

Только у меня в этот момент дернулся глаз? О какой защите через whitelisted IP может идти речь, если админ со своего компьютера все делает. Это фишка CSRF. Но дальше больше. Ответственный заявил следующее.

Bug#7 Я пока не понимаю, как это реализовать (с) Руководитель отдела тестирования

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

Можно разом перебрать все id

Как скомпрометировать систему документооборота в несколько кликов - 5

Ну и остановиться на тех которые нам не интересны

Как скомпрометировать систему документооборота в несколько кликов - 6

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

После всех переписок, уточнений, кучу потраченного времени, я был уведомлен о том, что мне будет выплачено вознаграждение по специальной багбаунти специально для меня. При этом расчет этого вознаграждения по сей день остается для меня какой-то магией. Хотя мне была приведена формула, по которой все посчитали.
Все XSS кроме одной посчитали дублями и просуммировали по понижающему коэффициенту. СSRF по другому коэффициенту.
В итоге я получил 100 Euro.

Как скомпрометировать систему документооборота в несколько кликов - 7

Но хорошо, что вообще что-то получил!

Из-за «интересной» политики поддержки пользователей, большинство клиентов так и останется без этих критических обновлений и исправлений.
Просто потому, что у этих клиентов нет годового абонемента поддержки. Так что в какой-то крупной компании, использующей этот дорогой продукт, по сей день можно утащить куки или сделать что-то от лица пользователя, подсунув картинку с котиками. Список клиентов внушителен — банки, страховые, промышленные холдинги...

В каком то смысле 0day получилась (уязвимость не имеющая исправления).

На мой взгляд можно бы было поступить разумнее и благороднее. Microsoft вон все еще патчи выпускает для Windows XP.

Раскрывать название компании и клиентов компании я не стал по морально-этическим соображениям.
Ну и представители за репутацию переживают.

Таймлайн:
19 июля — были сделаны репорты
9 августа — подтверждены все репорты и начислено вознаграждение
28 августа — исправлены проблемы с фильтрацией XSS
14 ноября — реализовали исправление CSRF для клиентов у которых есть абонемент поддержки

Автор: Валерий Шевченко

Источник

Поделиться

* - обязательные к заполнению поля