Pull to refresh

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

Reading time5 min
Views13K

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




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


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


Увидев input field, мне сразу же захотелось воткнуть туда xss. Воткнул банальный вектор


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

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




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


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


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


Пару слов о CSRF, хоть вы и могли бы загуглить это.


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



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


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


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

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


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



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



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


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


Все XSS кроме одной посчитали дублями и просуммировали по понижающему коэффициенту. СSRF по другому коэффициенту.


В итоге я получил 100 Euro.



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


Из-за «интересной» политики поддержки пользователей, большинство клиентов так и останется без этих критических обновлений и исправлений.


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


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


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


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


Ну и представители за репутацию переживают.


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

Tags:
Hubs:
Total votes 26: ↑25 and ↓1+24
Comments19

Articles