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

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 2 месяца
Сообщений: 27286

news_bot ^® написал(а)
01-Июл-2021 16:35

Цитировать

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

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

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

Максимально замедлить перебор пользовательских данных;
Не допустить массового списания баллов пользователей;
Внедрить ряд доработок, которые закроют брешь в системе;
Переработать систему авторизации и внедрить двухфакторную авторизацию через 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 месяца.К сожалению, с аналогичными кейсами сталкиваются многие компании, которые запускают программы лояльности. Все думают, что эта проблема обойдет их стороной, ведь они торгуют мебелью/одеждой/текстилем, но для злоумышленника размер компании значения не имеет. Они одинаково успешно проникают в программы лояльности федеральных банков и небольшой обувной мастерской. Компании, которые не предусматривают систему защиты, рискуют лишиться своей программы лояльности и получить справедливое негодование пользователей. Рекомендации для тех, кто хочет обезопасить свой продукт:

Если ваш сервис позволяет списывать баллы, защитите авторизацию или списание вторым фактором в виде SMS или PUSH;
Установите Application Firewall - это защитит систему от DDOS, а в случае атаки позволит быстро настроить защиту сервиса по необходимым правилам;
Настройте систему логирования - она позволит вам быстро найти слабое звено в своей системе;
Обвесьте вашу систему мониторингами, чтобы видеть рост нагрузки и иметь возможность быстрого реагирования.

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

Теги для поиска: #_informatsionnaja_bezopasnost (Информационная безопасность), #_programma_lojalnosti (программа лояльности), #_frod (фрод), #_blog_kompanii_agentstvo_agima (
Блог компании Агентство AGIMA
), #_informatsionnaja_bezopasnost (
Информационная безопасность
)

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 06-Май 16:22
Часовой пояс: UTC + 5