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

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

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