В России в условиях санкций растёт спрос на отечественные программные разработки, для создания которых нередко используется софт с открытым исходным кодом (Open Source). Чем это может обернуться? Какие опасные уязвимости присутствуют в финансовых приложениях и угрожают пользователям и организациям? Что интересует злоумышленников в первую очередь?
- Введение
- Уязвимости в коде приложения
- Уязвимости в библиотеках с открытым исходным кодом
- Уязвимости окружения
- Выводы
Введение
В России сегодня очень активно разрабатываются десятки тысяч программных продуктов, включая сайты, мобильные приложения и клиенты под различные операционные системы. Сегодня у каждого магазина, детского садика, даже, наверное, у каждой небольшой компании есть как минимум веб-сайт, а то и пара мобильных приложений. При этом, в 2020 г. по статистике Positive Technologies в 9 из 10 веб-приложений преступники могли проводить атаки на пользователей, и сейчас ситуация существенно не улучшилась. Что касается мобильных приложений, то каждое третье из тех, что поступают в российские магазины, уязвимо.
Наибольшую опасность представляют «дыры» в финансовых приложениях, поскольку через них злоумышленники могут похитить не только конфиденциальные данные пользователей, но и, получив доступ к аккаунту, денежные средства клиентов банков. Расскажем о самых популярных уязвимостях российского финансового сектора, а также о том, что они позволяют сделать и как от них защититься.
Рисунок 1. Уязвимости библиотек с открытым исходным кодом
Для начала стоит отметить, что каждое приложение состоит из нескольких основных частей:
- Самого приложения, код которого реализует бизнес-логику.
- Библиотек с открытым исходном кодом, очень часто и очень много используемых в современном ПО.
- Окружения, где запускается и работает приложение.
В каждой из этих частей могут быть самые различные уязвимости. Давайте более детально рассмотрим их.
Уязвимости в коде приложения
Код приложений пишут люди, пусть и обладающие техническими знаниями, но допускающие ошибки по неосторожности или по незнанию. Нередко именно поэтому в код попадают уязвимости.
К чему может привести их наличие в коде веб-приложений? Приведём самые распространённые проблемы. Согласно статистике, уязвимости делают возможным несанкционированный доступ к приложению (39 % сайтов), в 68 % веб-приложений из-за них присутствует угроза утечки важных данных. При этом в третьи руки попадают и персональные данные (47 % утечек), и в целом учётные данные (31 %).
Уязвимости, которые приводят к таким последствиям, могут быть самыми разными, начиная от незначительных ошибок и заканчивая самыми страшными из них, о которых бы хотелось рассказать подробнее.
На сегодняшний день, как бы это ни было странно, до сих пор в число самых распространённых уязвимостей входят XSS (53 %) и различного вида инъекции (29 %).
- XSS (англ. Cross-Site Scripting — «межсайтовый скриптинг») — это очень распространённая уязвимость в веб-приложениях, суть которой состоит во внедрении JavaScript-кода в страницу, загружаемую пользователем. Цель атаки — получить данные пользователя и дальше совершать различные действия от его имени (например, войти в систему и вывести деньги).
- Инъекции — одна из самых распространённых атак на серверную часть приложения. При её реализации злоумышленники применяют различные технологии. Чаще всего они атакуют базы данных (SQL-инъекции), операционную систему (Command-инъекции), внутренние сервисы компании (LDAP-инъекции), задействуют обработку различных форматов (XML-инъекции или XXE). В конечном итоге целью эксплуатации таких уязвимостей является получение пользовательских данных, хранящихся на сервере, или захват полного контроля над сервером.
Итак, через использование самых популярных проблем безопасности веб-приложений финансовой сферы могут быть атакованы как непосредственно клиенты, так и серверная часть (иначе говоря, инфраструктура организации целиком).
Для того чтобы не допускать таких проблем, необходимо обязательно проверять код разрабатываемых приложений и обучать разработчиков вопросам из области информационной безопасности.
Уязвимости в библиотеках с открытым исходным кодом
Однако уязвимости могут быть не только в коде, который пишут разработчики компании, но и в библиотеках с открытым исходным кодом, применяемых для упрощения и ускорения разработки. Согласно статистике, использование библиотек с открытым исходным кодом в больших проектах может достигать 30–40 % от всего кода приложения, а в некоторых случаях — и больше. Что и говорить, если за прошлый год появилось более 6 миллионов новых версий библиотек, а суммарное количество компонентов, которые можно использовать, превысило отметку в 37 миллионов. При этом количество загрузок различных библиотек составило более 2,2 триллиона за 2021 год.
Все эти библиотеки тоже пишут люди, которые могут допускать ошибки (и сейчас мы даже не говорим о случаях, когда туда специально встраивается вредоносная функциональность, что также нередко случается). В исследованиях отмечают, что более 29 % популярных библиотек содержат уязвимости, а количество атак через них увеличилось на 650 % по сравнению с прошлым годом.
И действительно, за последнее время атаки на приложения через библиотеки с открытым исходным кодом стали намного популярнее, некоторым уязвимостям даже стали давать имена. Вспомнить хотя бы нашумевшую недавно историю с Log4Shell, которая позволяла выполнить любой код на сервере удалённо! Если посмотреть на то, как её пытались использовать, то цифры получаются очень интересными. Во-первых, для реализации этой уязвимости было написано более 60 готовых эксплойтов и в отдельные промежутки времени можно было наблюдать до 100 попыток атак в минуту. Во-вторых, хакерские группировки суммарно провели более 1,5 миллиона атак, направленных на эту уязвимость, в течение первых четырёх дней после публикации уязвимости.
Рисунок 2. Количество атак через Log4Shell
И таких примеров — множество. Уязвимости в openSSL, который используется практически везде и который в 2014 году стал главной новостью и проблемой всех, кто занимается и разработкой, и безопасностью; уязвимость в библиотеке struts2, через которую произошёл самый массовый «слив» данных компании Equifax, и многое другое.
Для того чтобы избежать подобных проблем и всегда понимать, какие версии библиотеки используются в ваших продуктах и насколько они безопасны, необходимо проводить постоянный анализ библиотек с открытым исходным кодом.
Уязвимости окружения
В дополнение ко всем уязвимостям, перечисленным выше, отметим ещё один распространённый тип проблем информационной безопасности. Речь — о неправильно настроенном окружении приложений, когда уязвимости находятся не в самом приложении, а где-то рядом, например на некорректно сконфигурированном сервере, или появляются из-за неправильно настроенных параметров веб-сервера. Подобные баги, по статистике, встречаются в более чем 80 % приложений.
Одним из примеров такой уязвимости является отсутствие важных заголовков безопасности, которые сильно упрощают атаки на пользователей. Другой случай — попадание директорий, связанных с системой хранения версий кода (git или svn), на сайт, когда открывается возможность получения всего исходного кода сайта.
Примеры неправильной настройки веб-серверов и окружения можно перечислять очень долго. Они включают в себя и неправильно настроенный SSL, и возможность определения версий ПО, используемого на сервере (чтобы поискать в нём известные уязвимости), и незакрытые порты, и неправильную конфигурацию удалённого доступа к серверу, и учётные данные по умолчанию (кстати, это тоже одна из самых распространённых проблем), и многое другое.
Обычно такого рода уязвимости не так опасны, как два серьёзных типа проблем, описанные выше, но они заметно упрощают способы эксплуатации и предоставляют возможность для построения вектора атаки.
Конечно, их тоже нужно закрывать, а ещё лучше — не допускать их появления, всегда правильно настраивать все смежные системы и контролировать их конфигурацию. Помочь с этим могут, в частности, специализированные программы, проверяющие инструменты на соответствие лучшим практикам — к примеру, стандарту по безопасности настройки Docker-окружения CIS Benchmark.
Выводы
Какие выводы можно сделать из всего этого? Как минимум, такой: безопасность приложения — комплексное понятие, и при её обеспечении нужно учитывать не только код, который пишется разработчиками, но и безопасность компонентов с открытым исходным кодом, используемых в приложении, правильную конфигурацию сервера и окружения, обучение команды разработки и многие другие немаловажные вещи. Делать это максимально эффективно, не отвлекаясь на сроки выхода новой функциональности на рынок, поможет правильно выстроенный процесс разработки защищённых программных продуктов, с помощью которого можно бесшовно интегрировать ИБ в инженерный процесс.
Пользователям систем и услуг, в свою очередь, можно рекомендовать максимально задействовать все возможности, которые предоставляет система обеспечения безопасности данных. Как минимум, стоит следить за базовыми вещами:
- Если есть возможность, установить двухфакторную аутентификацию в приложении; да, это не всегда удобно, но даже если ваши учётные данные попадут в руки к злоумышленникам, им будет намного труднее завладеть вашим аккаунтом.
- Не использовать одинаковые пароли для различных сервисов. Чтобы помнить их все, можно воспользоваться удобными программами для хранения паролей.
- Всегда тщательно проверять, где и куда вы вводите свои данные, и быть внимательными при звонках с неизвестных номеров.
