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

Я Роман Кузьмин, аккаунт-директор AGIMA. В этом кейсе программа лояльности столкнулась с брутфорсом: злоумышленники перебирали логины и пароли, получали доступ к аккаунтам и списывали накопленные баллы.

Команда поэтапно ограничила перебор с помощью Web Application Firewall (WAF), протестировала капчу и внедрила двухфакторную авторизацию по SMS. Из-за NDA название компании не раскрывается.

Коротко

• подозрительную активность обнаружили через два дня после крупного релиза;
• WAF сократил автоматический перебор, но потребовал настройки правил;
• капча остановила часть запросов, однако вызвала волну пользовательских жалоб;
• двухфакторная авторизация усложнила списание баллов из скомпрометированных аккаунтов;
• последствия инцидента включали падение рейтинга приложения с 4,5 до 3,2 и задержку продуктового развития на три месяца.

Это разбор конкретного инцидента 2021 года, а не универсальная инструкция по информационной безопасности. Архитектуру защиты и реакцию на атаки нужно проектировать вместе с профильными специалистами.

Как обнаружили брутфорс

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

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

Как ограничивали перебор

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

1. Максимально замедлить перебор пользовательских данных;
2. Не допустить массового списания баллов пользователей;
3. Внедрить ряд доработок, которые закроют брешь в системе;
4. Переработать систему авторизации и внедрить двухфакторную авторизацию через SMS.

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

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

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

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

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

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

Как внедряли двухфакторную авторизацию

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

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

К такому сценарию подготовились заранее: подозрительную массовую отправку SMS дополнительно ограничивали капчей. Это снизило риск неконтролируемых расходов, но не отменяло необходимость мониторинга.

Последствия и выводы

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

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

Что учесть при проектировании защиты

1. Защищайте чувствительные действия дополнительным фактором — например, подтверждением по SMS или push-уведомлением.
2. Используйте WAF как один из уровней защиты приложения, а не как единственное средство против атак.
3. Настройте централизованное логирование событий авторизации и списания баллов.
4. Следите за нагрузкой, частотой неудачных входов, массовыми списаниями и расходами на SMS.
5. Подготовьте план реагирования, каналы связи с пользователями и сценарии временного ограничения операций.

Проектирование авторизации, интеграций и защиты критичных пользовательских сценариев входит в направление веб- и мобильной разработки AGIMA.