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