Ведущий эксперт по сетевым угрозам, web-разработчик компании «Код Безопасности» Константин Горбунов рассказал CISOCLUB о новых угрозах в мобильном банкинге и методах оперативного реагирования на инциденты.
С масштабным распространением ПО для мобильного банкинга пропорционально увеличивается и количество угроз. Причем их качество неизменно растет, отчего борьба разработчиков и злоумышленников напоминает бег по кругу. Программисты совершенствуют ПО – мошенники находят уязвимости и пытаются их эксплуатировать – разработчики закрывают уязвимости – хакеры находят новые – и так до бесконечности.
Впрочем, тема настолько сложная, что, рассматривая данный вопрос, следует разделить угрозы по направлениям.
Уязвимости клиентского и серверного ПО
В первую очередь это уязвимости клиентского ПО. К данной категории относятся уязвимости мобильных приложений банков, web-интерфейсов. Например, XSS-атаки, то есть межсайтовый скриптинг, при котором злоумышленники внедряют строки с вредоносным кодом в базу данных для последующего вывода и исполнения на странице пользователя. Такой сценарий возможен, если сама веб-страница, даже официальная, имеет недостаточную фильтрацию вводимых и выводимых данных.
Также к данному направлению относятся следующие уязвимости:
- небезопасное хранение данных. Приложения могут хранить локально конфиденциальные данные, например, пароль для автоматического логина пользователя в системе, то есть ему не требуется вводить свой код при каждом открытии банковского приложения. Если эти данные не зашифрованы, то злоумышленник сможет ими воспользоваться. Кроме того, существует множество вредоносов, которые, попав на устройство юзера, могут «вытаскивать» сохраненные пароли из браузеров.
- небезопасная передача данных. Отсутствие проверок ссылок API, передача чувствительных данных в GET-запросах могут привести к компрометации конфиденциальной информации.
- возможность декомпеляции исходного кода. Минимизация javascript-кода для web-приложений или же обфускация кода мобильных приложений затруднят злоумышленникам анализ бизнес-логики приложения, секретных данных для взаимодействия с сервером и другими API. Если же это не сделать на этапе сборки приложения, то хакеры без труда проанализируют вышеупомянутую информацию.
Следующее направление – уязвимости серверного ПО. Как и в случае с уязвимостями клиентского ПО, мы сталкиваемся с тем, что в погоне за скоростью и желанием оперативнее выпустить нужный для бизнеса и его клиентов софт разработчики зачастую уделяют недостаточное внимание безопасности.
Так, при проектировании современной архитектуры зачастую предпочтение отдается микросервисам, нежели монолитному приложению. Микросервисная архитектура характеризуется множеством, чаще всего асинхронных сервисов, которые выполняют отдельные задачи и для обмена данными используют брокер сообщений. Это позволяет разделить «ответственность» между различными сервисами, а также повышает общую отказоустойчивость.
Сервис – это своего рода Rest API, то есть набор эндпоинтов, по которым можно к нему обратиться и передать данные для дальнейшей обработки. Если сегментация доступа отсутствует или настроена некорректно (из-за скорости разработки такое случается нередко), остаются лишние открытые порты, тестовые методы, отсутствует проверка авторизации, чем и пользуются злоумышленники.
Также к уязвимостям серверного ПО стоит отнести недостаточную валидацию входящего запроса. Отсутствие проверок на XSS и SQL-инъекции откроют перед злоумышленниками возможность получить управление над базой данных, повысить свои привилегии или выкачать дамп.
Вслед за этим появляются и уязвимости методов авторизации. Это и некорректное сравнение хешей паролей пользователей, и низкие настройки безопасности. Например, длительное время действия одноразового кода или возможность его переиспользования при неудачных попытках ввода основного пароля открывают возможность перебора паролей или логинов учетных записей. Учитывая нынешние вычислительные мощности, хакерам не составит труда подобрать нужную комбинацию и заполучить доступ к тому или иному аккаунту.
Следует выделить и методы обработки ошибок. В тексте ошибки, возвращаемой от сервера, необходимо выводить минимум информации. Расширенный текст ошибок, включающий название файла, в котором она возникла, дает дополнительную информацию для злоумышленников.
Атаки на цепочку поставок и низкая ИБ-зрелость
В вопросах уязвимостей мобильного банкинга также стоит выделить компрометацию подрядных организаций.
Дело в том, что современный бизнес – это не всегда внутренний отдел разработки. Напротив, сегодня распространена практика условной если не экономии, то сбережения ресурсов. Поэтому многие ИТ-задачи выносятся на аутсорс, особенно те, которые можно отнести к разряду проектных, не влияющих на операционную деятельность бизнеса.
С одной стороны, это логично: если компания не имеет «айтишного» профиля, а большинство сервисов уже внедрены в бизнес-процессы, то нет нужды тратить деньги на постоянную команду. Гораздо выгоднее прибегать к проектному аутсорсу. С другой, аутсорсинговый подход чреват проблемами, в том случае, если компания не следует принципам безопасной разработки (Security Development Lifecycle, SDL). В это понятие входит:
- отдельная инфраструктура для партнеров, так называемая «песочница» для разработки;
- настройка pipeline, когда все обновления проходят рецензию кода, тестирование, аудит информационной безопасности и только потом попадают на основной сервер, иначе велик риск получить уязвимость в исходном коде или вовсе сделать его публичным.
- настройка CI\CD.
Отдельным пунктом стоит упомянуть низкий уровень «зрелости» некоторых подрядных организаций в контексте кибербезопасности. В том числе из-за этого процветает социальная инженерия. Не только «простые» пользователи, но и сотрудники на аутсорсе продолжают открывать и устанавливать вредоносные файлы, присланные под видом легитимных программ. После заражения подрядной ИТ-инфраструктуры дальнейшее проникновение в целевую компанию – дело техники.
Методы оперативного реагирования на инциденты
Почти все из перечисленных выше уязвимостей решаются повышением уровня ИБ-зрелости, которая в первую очередь заключается в понимании рисков и постоянной работой над их купированием. Впрочем, даже при высоком уровне зрелости возможны инциденты, и к ним нужно готовиться.
- Внедрять сервисы мониторинга, например SIEM, и контролировать подозрительную активность, в том числе вход с другого устройства, смену IP-адреса и так далее.
- Интегрировать в инфраструктуру сервисы WAF. Фактически они обеспечивают пассивную защиту от многих типов атак вроде SQL-инъекций или XSS.
- Использовать ИИ-технологии. Уже сейчас многие сервисы разрабатываются на базе нейросетей, которые позволяют профилировать каждого пользователя и составлять его «портрет». Как только юзер проявляет нехарактерную для себя активность, система будет оповещать об этом.
В заключение отметим, что многие упомянутые в материале угрозы – следствие не умелых действий хакеров, а халатное отношение организаций к своей ИТ-инфраструктуре. Чем больше внимание будет уделяться защите сервисов, тем сложнее злоумышленникам прорвать «оборону».
Оригинал публикации на сайте CISOCLUB: "Константин Горбунов («Код Безопасности») – о новых угрозах в мобильном банкинге".
Смотреть публикации по категориям: Новости | Мероприятия | Статьи | Обзоры | Отчеты | Интервью | Видео | Обучение | Вакансии | Утечки | Уязвимости | Сравнения | Дайджесты | Прочее.
Подписывайтесь на нас: VK | Rutube | Telegram | Дзен | YouTube.