Фрод, Application Firewall, неудачная капча и двухфакторная авторизация: как мы нашли и устранили проблему в приложении

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!

Привет, Хабр!

Я Рома, руковожу проектным офисом в AGIMA. До этого на протяжении пяти лет я был руководителем проектов и работал над многими программами лояльности. Каждую из них пытались взломать. В этой статье расскажу про одну из самых ярких историй взлома и о том, как мы с ним боролись.

По условиям NDA мы не можем называть компанию, поэтому в статье будет собирательный образ «Заказчика».

Фрод: как всё начиналось

Четыре месяца две команды по шесть разработчиков внедряли новую функциональность, которая повлекла кардинальное изменение продукта. Релиз прошел успешно, заказчик был доволен, пользователи получили масштабное обновление с полезными функциями. После таких релизов хочется немного передохнуть, подтянуть «хвосты» и спланировать дальнейшее развитие продукта. «Отдых» был недолгим: через два дня после релиза служба безопасности сообщила, что в запросах к внутренним системам лояльности обнаружилась подозрительная активность.

Так мы узнали, что у нас брутфорс: злоумышленники перебирали сочетания логинов/паролей и списывали накопленные баллы пользователей из мобильного приложения.

Быстрое реагирование: разрабатываем план действий и корректируем его по ходу дела

Сразу после новостей от службы безопасности мы начали выстраивать план по устранению бреши. Общая концепция была такой:

  1. Максимально замедлить перебор пользовательских данных;

  2. Не допустить массового списания баллов пользователей;

  3. Внедрить ряд доработок, которые закроют брешь в системе;

  4. Переработать систему авторизации и внедрить двухфакторную авторизацию через SMS.

Казалось бы, у нас есть план и нужно его придерживаться, однако проблема усугублялась постоянными падениями сервиса из-за резкого всплеска нагрузки. Безостановочный многопоточный перебор работал по принципу DDOS-атаки и создавал повышенную нагрузку на сервис. А еще на носу были новогодние праздники, когда пользователи особенно активно тратят накопленные за год баллы. В общем, мы просто не могли взять и приостановить работу программу лояльности.

Чтобы замедлить переборы, установили сторонний Web Application Firewall. Этот способ хорош своей простотой установки и наличием настраиваемых правил блокировки, которые смогут автоматически отсекать злоумышленников. Кроме WAF, мы рассматривали внедрение Proof-of-Work и капчи. От Proof-of-Work отказались из-за высоких трудозатрат на внедрение и дальнейшую поддержку, а капчу оставили на второй этап.

Одна неделя ушла на установку Application Firewall и еще две на тонкую настройку правил, по которым запросы настоящих пользователей отсеивали от запросов злоумышленников. Общая логика работы правил WAF: «если настоящий пользователь выполнил запрос X, за ним обязательно должен быть запрос Y. Если запрос Y не последовал, значит, это запрос от злоумышленника, блокируем». Такой подход помог существенно сократить перебор — каждый день мы блокировали десятки тысяч IP-адресов. Оппоненты по ту сторону системы поняли, что им дан бой, и начали перестраивать свои скрипты на имитацию пользовательских действий. Брутфорс возобновился, но уже в меньших масштабах.

Нам хотелось свести брутфорс к минимуму в самые короткие сроки, поэтому к WAF добавилась капча. Капча в мобильном приложении - зло. А капча в мобильном приложении, когда ты стоишь на кассе в магазине - зло, за которое тебя будут проклинать долгие годы.

Чтобы избежать проклятий, капча должна была появляться только в момент первичной авторизации. С технической точки зрения все сработало отлично: мы тестово запустили капчу на 30 минут, и нагрузка на сервис моментально спала, отсеялся оставшийся перебор данных. Но что-то пошло не так: в социальных сетях заказчика стали появляться сообщения от разгневанных пользователей, которым пришлось выбирать картинки со светофорами каждый раз при запуске мобильного приложения. Колл-центр также начал рапортовать о множестве жалоб на телефон горячей линии.

Мы не понимали что происходит, ведь никаких светофоров быть не должно, наверное, мы пропустили ошибку в прод. Капчу пришлось срочно выключать и проверять всю систему повторно. Ошибку мы так и не нашли, но стоило нам только включить капчу, как пользователи начинали писать в соцсети, звонить в колл-центр и описывать проблему капчи, которая блокировала работу мобильного приложения.

Добавляем двухфакторную авторизацию и знакомимся со злоумышленниками

Провал с капчей ускорил нас с внедрением двухфакторной авторизации, и пока мы над ней работали, один из разработчиков нашел закрытый Telegram-чат, посвященный взломам программ лояльности. 700 человек хвастались друг перед другом своими «покупками» на украденные у обычных пользователей баллы. Координаторы чата раздавали задания и организовывали атаки на социальные сети нашего заказчика с фейковых аккаунтов. Оказалось, что под натиском сотен сообщений мы искали проблему, которой не было.

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

К такому развитию событий мы подготовились заранее: при малейшей попытке совершить атаку на SMS, она тут же прикрывалась капчей - система была защищена на 100%.

Итоги: как подготовиться к атакам и защитить свой продукт

История закончилась тысячей негативных отзывов о работе сервиса, с которыми нам пришлось разбираться еще долгие месяцы. Рейтинг приложений в сторах снизился с 4,5 до 3,2, а продуктовое развитие проекта затормозилось на 3 месяца.

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

Рекомендации для тех, кто хочет обезопасить свой продукт:

  1. Если ваш сервис позволяет списывать баллы, защитите авторизацию или списание вторым фактором в виде SMS или PUSH;

  2. Установите Application Firewall - это защитит систему от DDOS, а в случае атаки позволит быстро настроить защиту сервиса по необходимым правилам;

  3. Настройте систему логирования - она позволит вам быстро найти слабое звено в своей системе;

  4. Обвесьте вашу систему мониторингами, чтобы видеть рост нагрузки и иметь возможность быстрого реагирования.

Если у вас тоже были подобные случаи, расскажите о них в комментариях. =)

Источник: https://habr.com/ru/company/agima/blog/565080/


Интересные статьи

Интересные статьи

Как структурировать sass/scss файлы в проекте Angular? Однажды задавшись этим вопросом, нашел несколько вариантов. Читать далее
Цифровая археология — неофициальное направление в IT, которое помогает найти и спасти от забвения многие интересные изобретения прошлых лет. Игры, ноутбуки, КПК, аксессуары — многие гад...
История сегодня пойдёт про автосервис в Москве и его продвижении в течении 8 месяцев. Первое знакомство было ещё пару лет назад при странных обстоятельствах. Пришёл автосервис за заявками,...
Я руковожу лингвистической онлайн-школой GLASHA. И еще совсем недавно для связи в нашей компании чаще всего пользовались электронной почтой и Скайпом. Но культура коммуникации эволюционирует. Мно...
Как обновить ядро 1С-Битрикс без единой секунды простоя и с гарантией работоспособности платформы? Если вы не можете закрыть сайт на техобслуживание, и не хотите экстренно разворачивать сайт из бэкапа...