На пороге уже стоит 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 для клиентов у которых есть абонемент поддержки
Комментарии (17)
Metus
20.12.2017 17:57Если нет никаких договоров о неразглашении, не раскрывать подобную компанию аморально, а не наоборот.
pansa
21.12.2017 01:01Вы молодец, что нашли и зарепортили. Однако, если беспрестрастно, то статья вызывает смешанные чувства.
> Но хорошо, что вообще что-то получил!
Вы сами сказали, что у компании нет багбаунти. Время вы тратили сами, вас никто не заставлял и не просил.
В таком случае 100E — это, правда, более, чем неплохая выплата. Да еще и расписали, как посчитали сумму! Право, вы придираетесь.
> Из-за «интересной» политики поддержки пользователей, большинство клиентов так и останется без этих критических обновлений и исправлений.
В чем интересность политики, дайте ссылку или текст? Откуда вывод про большинство клиентов — как считали? Компания реально не даёт обновления безопасности коммерческим клиентам?
Простите, не поверю без пруфов. Если это правда, то скрывать нечего — таких «героев» должны знать.
> В каком то смысле 0day получилась (уязвимость не имеющая исправления).
Это совершенно не 0day.
>На мой взгляд можно бы было поступить разумнее и благороднее. Microsoft вон все еще патчи выпускает для Windows XP.
Разумнее, благороднее — это красивые слова. Как именно они должны были поступить и что они не сделали? За M$ — вот не надо, вы вряд ли знаете, какие выкрутасы они вытворяют с вендорами по безопасности.
Таймлайн, кстати, тоже вполне даже приличный. 1 мес на XSS и 3 мес на CSRF для реально сложного продукта (а ДО это реально сложно ) — весьма и весьма хорошая скорость. Это же не овносайтик пропатчить, простите. В любой серьезный интерпайз выпускать фиксы надо крайне осторожно. Вот придется поподдерживать продукты с >100k пользователями на разнообразных платформах — ощутите =)
Valya-roller Автор
21.12.2017 01:38>В таком случае 100E — это, правда, более, чем неплохая выплата. Да еще и расписали, как посчитали сумму! Право, вы придираетесь.
Мое возмущение вызвала не сумма а расчет. Никогда не встречал, на том же h1, когда к примеру одну xss считали как баг. А все остальные xss этого же продукта помечали дублями. Это даже с точки зрения QA коим я являюсь — неправильно.
>В чем интересность политики, дайте ссылку или текст? Откуда вывод про большинство клиентов — как считали? Компания реально не даёт обновления безопасности коммерческим клиентам?
Ссылку или текст не приведу. Но к сожалению все что я написал — не вымысел. Подтверждение я получил и от исполнительного директора данной компании. И от руководителя отдела тестирования. Да и задавал я вопрос по обновлению всех клиентов не на ровном месте. У меня за плечами опыт работы в течении нескольких лет на компанию разработчика подобного продукта. Там политики поддержки клиентов были абсолютно такие же. И от части я даже понимаю почему. Когда продукт прошел несколько ступеней развития, то внести любые существенные изменения во все версии крайне сложно. Не потому что их много. А потому что продукт-конструктор со своей прикладной бизнес логикой. Покрыть тестами все сочетания версий и конфигураций невероятно сложно. А прикладная разработка для каждой компании в процессе внедрения становится уникальной. Взять риск на то что ничего не ушатается при обновлении — точно никто не захочет.
>Это совершенно не 0day.
Не спорю. Согласен.
>Таймлайн, кстати, тоже вполне даже приличный.
Таймлайн стал таким, когда я озвучил что хотел бы опубликовать рассказ о подобных проблемах. Дабы люди не забывали что многие баги живут и по сей день. И как их тестировать. Практически сразу исполнительный директор подключился. И сроки исправления были обозначены реальные.pansa
21.12.2017 02:08> Мое возмущение вызвала не сумма а расчет.
Вы противоречите сами себе.
Если вам важен фикс, то какая разница, как считали сумму.
Если вам важна сумма, то ваше возмущение можно понять.
> Никогда не встречал, на том же h1, когда к примеру одну xss считали как баг. А все остальные xss этого же продукта помечали дублями. Это даже с точки зрения QA коим я являюсь — неправильно.
Нууу… Здесь нельзя сказать определенно, не видя код. XSS это же проблема фильтрации ввода. Если весь ввод идёт через один интерфейс, то это именно 1 баг, а вы всего лишь нашли несколько его проявлений. Совершенно стандартная ситуация.
> Ссылку или текст не приведу. Но к сожалению все что я написал — не вымысел.
Ну хоть своими словами — в чем конкретно эта ужасная «интересность»? Не то, чтобы я не верил вашим словам, скорее я уверен в различной интерпретации. Но без текста говорить серьезно не о чем, и обвинять в «неправильности» — также некорректно.
> Таймлайн стал таким, когда я озвучил что хотел бы опубликовать рассказ о подобных проблемах.
Ох ох, чем дальше в лес, тем толще партизаны.
Простите, вот это уже звучит, как шантаж чистой воды.
Не говоря о том, что что БЫЛО БЫ, если БЫ — это сослагательное наклонение, которое выражает лишь ваше предположение.
fukkit
21.12.2017 10:22И чего это вы к человеку прицепились?
Да, статья раздутая, да XSS тривиальный, да автор любит деньги и славу не меньше остальных людей, но еще не научился это правдоподобно скрывать на письме.
Нет, косякнувшая сторона не молодцы, таймлайн приличный только до начисления вознаграждения, нет сброс паролей не стоит EUR100, как бы кто к этому не относился, если продукт хоть немного рыночный — от 1к. А разумный менеджер рассмотрел бы возможность сконтрактоваться на дополнительный аудит.
Обновления с фиксами только для обладателей «абонемента поддержки» — вот где шантаж чистой воды и свинство. Если вывоз за собою де*ьма кому-то в сладких снах представляется поддержкой, а не гарантийным обслуживанием, он имеет неиллюзорные шансы поближе познакомиться с реалиями действующего законодательства (и быть оплёванным в приличном обществе, разумеется).pansa
21.12.2017 14:42> нет сброс паролей не стоит EUR100,
Стоимость бага определяет владелец. В данном случае программы бб вообще не было.
Пришел человек, нашел баги (молодец), и под угрозой дисклоза требует скорейшего фикса. При том, даже не являясь клиентом. Как бы весьма сомнительное поведение.
>Обновления с фиксами только для обладателей «абонемента поддержки» — вот где шантаж чистой воды и свинство.
Абсолютно согласен. Поэтому и не верю на слово, и прошу конкретные тексты соглашений, т.к слишком очевидное свинство =)
Valya-roller Автор
21.12.2017 16:27>Стоимость бага определяет владелец. В данном случае программы бб вообще не было.
Пришел человек, нашел баги (молодец), и под угрозой дисклоза требует скорейшего фикса. При том, даже не являясь клиентом. Как бы весьма сомнительное поведение.
Попробую до вас донести свою «философию» еще раз. Я никогда не был материально-заинтересованным человеком работая на ту или иную компанию. Обычно мои материальные потребности закрывала внерабочая деятельность. После переезда все немного поменялось конечно, «философия» осталась, но это уже личное. Угрозу дисклоза для компании я не создавал и всегда оставался открытым для общения. Для компании я озвучивал возможность опубликовать историю только лишь по одной причине — после продолжительного молчания с их стороны было четкое ощущение что проблема уходит в бэклог. И мне было грустно наблюдать пассивную реакцию на происходящее. Я никогда не понимал и не понимаю когда кто-то находит проблему и публикует ее до фикса. Я всегда держу в голове ст.272 и возможные последствия. И я не сторонник называть названия компаний. Т.к понимаю что мои скилы не достаточные для того что бы увидеть все угрозы и риски. И есть вероятность что после публикации названия, придет более скиловый товарищ и сделает что-то непоправимое в отношении компании и ее клиентов. Публикацию я написал лишь в образовательных целях. Дабы мои коллеги не забывали включать базовые проверки безопасности того что тестируют. Ведь тестировщики — это первые люди которые видят продукт до выкладки на прод. И в их руках ответственность за то что случится после выкладки. Ну, а компании, как я считаю, должны периодически заказывать квалифицированный пентест продукта. У меня все.pansa
22.12.2017 01:03Ну попробуйте донести =)
Давайте смотреть. Вы пишите:
" Для компании я озвучивал возможность опубликовать историю только лишь по одной причине — после продолжительного молчания с их стороны было четкое ощущение что проблема уходит в бэклог. "
Далее, из вашей статьи:
«19 июля — были сделаны репорты
9 августа — подтверждены все репорты и начислено вознаграждение»
Вот даже если тупо вычесть — от репорта до выплаты прошло 3 недели. Вы же упоминали h1, значит вам должны быть приблизительно знакомы расклады по времени, и вы прекрасно знаете, что 3 недели — это быстрая реакция. Это для компаний, которые _специально_ ведут бб.
Посчитаем теперь точнее. 19 июля — это среда, середина рабочей недели. На чей-то email среди гор спама прилетает ваш репорт (или у них есть публичный багтрекер? вряд ли).
Его могли пропустить, не понять, отодвинуть. Ок, допустим сообщение перенаправляют разработке. Скорее всего до понедельника им серьезно заняться не успеют, даже если приняли и поняли.
Итак, у нас осталось 2 недели + пара дней до выплаты вам денег.
Идём дальше. Июль-август — это период отпусков, все планы нужно слепо умножать на 2-3, потому что — увы, мало кому под силу держать реплику к каждому разработчику, а людям над отдыхать и они обычно хотят делать это летом.
В это оставшееся время нам следует уложить, очень утрировано:
— организацию общения с вами
— воспроизведение бага, заведение репортов, корректировка текущих планов из-за фиксов
— анализ проблемы, поиск решения, фактический фикс
— прогон тестов, тестовые сборки, передача в тестинг
— прогон тестов, регрессий, итп
— подготовка и выпуск релиза/фикса в паблик
Дальше, не знаю о какой стране речь, но скорее всего так везде: юр лицо не может вот так взять и просто начислить вам даже 1$, с записью в бухгалтерии «ну вот Вася нашел баг и мы решили заплатить ему денег». Т.е даже не говоря о размере выплаты, нужно организовать финансовые моменты, чтобы законно перечислить вам денег.
Я напомню, у нас на дворе лето и это, вероятно, более-менее крупная организация. Увы, с ростом организцаии — растёт и бюрократия, замедляющая процессы, это просто факт.
Поэтому я выступаю на стороне защиты нашей неведомой компании. Если даты в вашей же статье правильные, то у вас просто не было времени на «четкое ощущение что проблема уходит в бэклог.» Ну вот просто по календарю — не было =)
shanker
А Вы подписывали какие-то документы о нераспространении информации? Если нет — может, стоит поинтересоваться у представителей компании-разработчика не против ли они, чтоб Вы раскрыли продукт и компанию? Если не против — смело тут их указывайте. А если против — намекнуть, что Вы готовы заключить соглашение о нераспространении, но не за бесплатно. Может, удастся на этом «поднять» больше 100 евробаксов.
Заодно можно ссылку на эту статью кинуть — возможно, это повлияет на окончательную стоимость, на которой остановитесь. Всё же одно дело в бложике с 3 читателями, и другое — на крупном ресурсе
ivanius
Я думаю автор, сильно схож со мной и что потраченое собственное время, которое я должен был потратить на
жену и детейотдых, я потратил на задачу, которая сильно меня вовлекла и выйти из этой матрицы уже было нельзя, а там хорошо что вообще за это заплатили, ибо я все проделал чисто из соственного любопытства и для возможного развития.По крайней мере у меня так часто бывает, а изменить себя сложно и некому.
Valya-roller Автор
Нет, я ничего не подписывал. Но и делал это все не ради денег и славы. Меня реально вовлекло. А «рекетирством» теперь заниматься как то некрасиво.
Valya-roller Автор
У меня ситуация как и у человека с ником ivanius. Меня сейчас расстраивает не размер вознаграждения. А то что исправление многие клиенты не получат…
ildarz
Публичное раскрытие уязвимостей из принципиальных соображений я могу понять, но шантаж в личных корыстных целях… в общем, очень хорошо, что позиция автора отличается от вашей.
shanker
Valya-roller ildarz
Господа, где в моих словах вы услышали что-то про рекет и шантаж? Может, разберёмся в терминологии? Я вот сейчас на всякий случай специально загуглил: мало ли — вдруг отстал от изменений в родном языке. Но нет. Как и ожидалось, синонимы этих слов — угроза и вымогательство. А про вежливый деловой разговор приходилось что-то слышать?
Если человек не умеет стоить свою речь иначе как: «не заплатите мне бабла — выложу с потрохами» — это действительно похоже на угрозу и вымогательство. А речь вроде: «Теперь, когда пофикшены дыры в продуктах, Вы не против, если я раскрою информацию о найденных багах и предостерегу пользователей, которым Вы не будете поставлять обновления? Если находите раскрытие этих фактов чувствительными — может, заключим соглашение о нераспространении, где будет изложено что можно раскрывать, а что — нет?» И дальше уж условия, на которых договоритесь. Заодно подсветив своё человеческое желание защитить клиентов, которым обновления не видать. Если уж они так и не засобираются обновления им бесплатно выкатить.
Разумеется, дальше развитие ситуации зависит от умения найти общий язык и заинтересовать другую сторону. Это уже не угрозы, а вполне вежливый деловой разговор. Удивительно, что приходится объяснять такие вещи. Возможна даже ситуация, когда услышите что-то вроде: «Делайте что хотите, но если нам это не понравится — затаскаем по судам». Или вообще окажется, что изучаемое ПО поставляется с Соглашением, в котором чётко прописан запрет на изучение или распространении какой-то информации. Тут уж действительно стоит подумать стоит ли овчинка выделки.
murzik_a
А может даже пофиксят дырки =D