НЕ ВСЕГДА ЦЕЛЬ – КРАЖА
Мы уже пять лет говорим на различных конференциях и страницах популярных изданий о необходимости защиты столь критичной системы для каждого банка. И это породило уже ряд «подвижек» и перемен в лучшую сторону, как в конкретных банках, так и в отрасли в целом. Но сегодня, в этой статье, хотелось бы рассказать о том, что атаки на ДБО – это не единственный способ кражи денег у банков и их клиентов и что есть целый ряд других способов.
Сразу внесем некоторое пояснение. Хотя здесь и будет описан потенциальный путь злоумышленника для кражи денег, но на самом деле кража – не всегда цель. Так, например, очень часто устраивают атаки на отказ в обслуживании ДБО-системы (DoS/DDoS) для того, чтобы сокрыть проведение мошеннических операций. Или злоумышленники могут вывести какую-нибудь критичную систему (например, центральную АБС банка) из строя на недельку и о последствиях (не считая огромных финансовых потерь) даже сложно судить.
Давайте же взглянем на ситуацию с точки зрения злоумышленника. Есть банк и у него есть ряд ресурсов, доступных из сети интернет. Обычно это, как минимум, корпоративный сайт, ДБО-система и какие-то дополнительные сетевые сервисы (VPN, например). Если система ДБО достаточно хорошо защищена, то прямой выгоды злоумышленнику вроде бы не получить.
Но это не так. Если злоумышленник сможет получить доступ во внутреннюю сеть, то спектр возможностей его и целей значительно расширится. Причём ему не обязательно приходить в офис банка и подключаться к сети. Ведь захватив удалённый контроль даже над одним компьютером в сети банка, злоумышленник может проводить атаки на внутренние системы.
С учётом развитости хакерского инструментария сейчас нет особых затруднений в проведении атак через подконтрольный промежуточный хост на другие системы. То есть захваченный компьютер в сети банка будет передавать в системы банка те запросы, которые необходимы злоумышленнику, и пересылать ответы на них через интернет обратно злоумышленнику, который физически может находиться где угодно.
АТАКИ С РАЗНЫХ НАПРАВЛЕНИЙ
Здесь важно понять, что проводить атаки через один промежуточный хост – это технически очень просто. Важнейшая задача для злоумышленника – захватить контроль хотя бы над одним хостом. Реально всё зависит от конкретной ситуации, но есть и ряд типовых сценариев.
Самая простейшая – инсайдерская атака. Можно подговорить кого-то, даже уборщицу, просто вставить специальную флешку с трояном на пару минут в компьютер любого из сотрудников, даже секретарши. И всё, доступ получен, а виновника – не найдёшь.
Вариант второй: социальная инженерия. У нас систематически заказывают работы по проведению атак с использованием социальной инженерии, когда мы массово рассылаем письма работникам компании с просьбой зайти какой-то сайт и/или с просьбой открыть какой-то PDF или даже EXE-файл. Данные файлы/сайты содержат эксплойты с кодом, позволяющим захватить контроль над компьютером. Итоги шокирующие: на сайты переходит больше 50% пользователей, а фактически удалённый контроль захватывается 20-30% случаев.
При этом стоит отметить, что используются эксплойты не «нулевого дня» (т.е. для которых уже есть официальные исправления от производителя ПО), так как косвенно с социальной инженерией проверяется эффективность работы антивируса, а так же обновлений клиентского ПО. При использовании эксплойтов «нулевого дня» – ни антивирус, не обновленность ПО не поможет (об этом далее). Хотя даже так должно быть понятно, что антивирус – это защита только от массовых хорошо известных вирусов и хоть какое-то отклонение сводит эту защиту на нет, что и показывает наша статистика.
А между тем, здесь стоит учитывать, что такие важные с точки зрения безопасности пользователи банка, как операторы ДБО, очень часто обязаны открывать всё, что приходит от клиентов банка (коим, зачастую, может стать любой желающий). И давайте помнить, что злоумышленнику нужен хотя бы один захваченный компьютер, а не все 20 %...
И третий вариант, он касается уже атак на внешние сервисы банка, доступные из сети Интернет. Хотя я и сказал, что зачастую они не представляют особого интереса, но фактически это не так. В некоторых случаях через них можно получить прямой доступ к корпоративной сети.
РАЗНООБРАЗИЕ УЯЗВИМОСТЕЙ
Например, не раз мы во время внешних пен-тестов (по сути, эмуляции действий злоумышленника) находили открытый административный интерфейс от корпоративного сайта или даже ДБО. Имея доступ к такому функционалу (из административного интерфейса мы очень часто можем выполнять команды ОС или записывать произвольные файлы) ничто не помешало бы злоумышленнику спрятать на сервере «троян» и иметь впоследствии удалённый доступ к нему и во внутреннюю сеть банка.
Другой показательный пример мы могли наблюдать этим летом. Есть такой фреймворк – Struts2. Он очень распространён и используется во многих веб-приложениях, в том числе, в банках. Так этим летом на сайте разработчиков Struts2 было опубликовано уведомление о закрытии критичной уязвимости, которая позволяла любому (анонимному) пользователю выполнять команды в ОС в любом веб-приложении на Struts2 (т.е. захватывать полный контроль над сервером). Разработчики приложили необходимое обновление, закрывающее уязвимость, и просили всех срочно обновиться.
Примерно через день в сети интернет появился эксплойт, позволяющий эксплуатировать данную уязвимость. Т.е. «оружие» попало в массы. Через несколько дней прокатилась массовая волна атак, а ещё через неделю в сети уже хозяйничал вирус, который автоматически выискивал сервера и захватывал контроль над ними, используя эту уязвимость. Но самое неприятное было в том, что даже почти через месяц многие организации не обновили версию Struts2 и поэтому были беззащитны перед этой угрозой В подтверждение этого мы провели небольшое исследование и обнаружили ряд финансовых организаций, и в частности банков, у которых не было обновлений. Соответственно, захватить контроль над их серверами мог любой желающий.
Дело в том, что у многих банков плохо поставлен процесс обновления ПО, происходит это редко, иногда перерывы составляют полгода и более. А злоумышленники обычно гораздо более оперативны. Есть, конечно, и другие пути для проникновения внутрь банка, но наша цель сейчас не перечислить их все, а просто показать, что это и возможно, и не трудно.
Перейдём к следующему этапу. Для начала давайте взглянем на потенциальные цели злоумышленника. Как минимум две системы банка работают напрямую с деньгами клиентов – это ДБО и центральная АБС. Вот их-то злоумышленник и будет атаковать в первую очередь. А точнее, он будет атаковать базы данных этих систем. Ведь БД – это самое важное, они открывают доступ к деньгам.
Таким образом, доступ злоумышленника в базу данных может способствовать переводу денег откуда угодно и куда угодно. Полная свобода действий.
ПРИМЕРЫ АТАК
Здесь стоит отметить, что база данных ДБО всё-таки содержит информацию не о «реальных» деньгах, а лишь передаёт информацию об операциях в центральную АБС. Но, мы не раз рассказывали про одну из очень распространённых проблем в наших банках – отсутствие проверки электронной подписи клиента при выгрузке платёжных поручений из ДБО в АБС.
Т.е. злоумышленник, получив доступ в БД ДБО, может сделать поддельную запись о платёжном поручения от любого клиента на любой счёт, при этом поставить лишь «галочку», что подпись данного платежного поручения была проверена и, что оно может быть выгружено в АБС. Дальше это поручение автоматически уйдёт и исполнится в АБС. Таким образом, важно понимать, что после того, как злоумышленник получит доступ в БД, его почти ничто остановить не сможет.
Путей получения доступа в БД, имея доступ к корпоративной сети банка (через захваченный хост), очень много. Можно привести пару примеров.
Во-первых, это корпоративный домен на базе MS AD. Без корректной и хорошей настройки он представляет собой достаточно слабо защищённую инфраструктуру, особенно, если злоумышленник имеет доступ хотя бы к одному из компьютеров, входящих в домен (а в нашем сценарии это так). Одной из основных проблем AD является его глубокая интеграция. И если злоумышленник захватит контроль хотя бы над одним хостом, то он сможет вынуть из его памяти учётные данные какого-то множества пользователей, и, используя их, будет захватывать контроль над другими серверами, вытаскивать учётные данные оттуда и продолжать атаку.
Итогом окажется нахождение учётной записи, имеющей доступ на сервер базы данных ДБО или АБС. На первый взгляд, кажется, что это непросто. Однако, описанная выше техника ? одна из самых распространённых и хорошо проработанных. К тому же, она давно автоматизирована.
Второй пример – это уязвимости конкретной АБС или ДБО, а так же их компонентов. Возможностей для атаки изнутри сети гораздо больше, чем снаружи. Так, были случаи, когда, например, любой пользователь сети имел возможность аутентифицировать в системе с максимальными правами, просто зная имя администратора системы. Или, например, когда через веб-функционал системы, созданный для работы с клиентами ДБО, любой пользователь корпоративной сети мог без аутентификации читать файлы сервера. И, как вариант, прочитать файл с паролем от базы данных ДБО.
Кроме того, те же базы данных от компании Oracle, по некоторым мнениям, содержат ряд критичных уязвимостей, которые разработчик не исправит в ближайший год-два точно (архитектурные уязвимости). А вот злоумышленник ими воспользоваться может и получить доступ в БД. Причём для этого ему даже не нужны учётные данные.
Третий пример – это множественные варианты атак на внутренних пользователей: администраторов или операторов. Мы уже не раз говорили, что, например, в ДБО-системе от BSS любой оператор имеет максимальные права в базе данных. Т.е. всё, что нужно, – получить доступ на компьютер оператора.
Таким образом, мы видим, что злоумышленник достаточно просто может атаковать внутренние системы банка и получить от этого большую финансовую выгоду. Ведь всё, что ему нужно – захватить один из хостов внутри корпоративной сети, что достаточно просто, и он будет обладать потенциалом доступа к внутренним системам.
ПРОЦЕСС КОМПЛЕКСНЫЙ И ИЗМЕНЯЮЩИЙСЯ
Как же защитить себя? Надо помнить, что безопасность – это комплексный и изменяющийся процесс, так что «серебряной пули» не существует. Перечислим основные пункты.
Во-первых, это хорошая сегментация сети, а также строгие правила на файерволлах. Как показывает опыт наших внутренних аудитов, этим пренебрегают в очень многих банках. Но на самом деле, если сеть правильно сегментирована, то трудозатраты злоумышленника значительно возрастают. Так, с качественной зоной DMZ, злоумышленник, взломав какой-то внешний ресурс (например, используя ту же уязвимость в Struts2) не сможет проникнуть глубже, попасть внутрь компании. Так же проблему с базами данных Oracle, описанную выше, можно свести на нет, строго ограничив набор хостов, которые имеют возможность подключаться к базе данных.
Во-вторых, это инвентаризация и обновление программного обеспечения. Это сверхнеобходимо – знать, что есть и внутри, и особенно снаружи вашей сети. Причём не просто знать название программного обеспечения, а иметь представление о его версии и возможностях, версии дополнительных модулей и библиотек. Ведь наверняка многие, у кого произошёл инцидент с уязвимостью Struts2, даже не знали, что этот фреймворк был использован в качестве основы их веб-приложения.
Зная, что установлено в системе, мы сможем осуществлять мониторинг публичных уязвимостей и обновлений. А обновлять ПО – очень и очень важно. Большая часть атак на типовые продукты (вне зависимости от вида ПО) – это атаки с использованием известных уязвимостей, для которых уже есть исправления от разработчика.
В-третьих, это корректная настройка имеющегося ПО. Административные интерфейсы не должны быть доступны всем, пароли должны быть стойкими, сервисы необходимо настраивать с использованием методик «Best Practice».
Тут стоит упомянуть про социальную инженерию. Человеческий фактор исправить трудно, но ограничить настройками – легко. Так, например, по статистике атак на пользователей, примерно в 7 случаях из 10 для захвата контроля используются уязвимости в Java. При этом надо понимать, что для Java систематически появляются в общем доступе уязвимости «нулевого дня» (без исправлений от разработчика) и обновления здесь не является решением, так как атака может произойти до выпуска обновления.
Зато корректными настройками мы можем ограничить всех пользователей от использования Java, за исключением тех, кому это реально необходимо (а таких будет совсем не много). Ну и конечно, систему надо проверять. Пен-тест, или глубже – аудит, покажет, каков же реальный уровень защищённости системы, что же злоумышленник сможет сделать с вашей системой.
НАПАДЕНИЕ ИЗНУТРИ
Анализ безопасности особенно важен для кастомизированных систем и решений от разрабочиков, у которых не отлажен процесс анализа безопасности продуктов. Ведь найти уязвимости в продуктах того же Microsoft – это большой труд (не даром за них платят сотни тысяч долларов на черном рынке). А вот уровень безопасности отечественных ДБО-систем (можем говорить это исходя из личного опыта) – откровенно низкий, а потому количество уязвимостей поражает.
В заключение хотелось бы донести ту мысль, что банки – это деньги, и атаки на них и их клиентов будут продолжаться. Необходимо постоянно помнить о том, что атаковать можно и достаточно просто изнутри банка, причём уровень успеха высок из-за низкой защищённости внутренних ресурсов.
Центробанк выпускает новый стандарт, посвященный жизненному циклу АБС, описывающий не только защиту ДБО, но и возможности по обеспечению безопасности любой банковской системы целиком, включая все подсистемы. Мы так же участвовали в его создании и можем подтвердить, что его применение позволит значительно поднять уровень защищённости банков, особенно изнутри.
В процессе подготовки этой статьи появились интересная новость. Прошла информация об официально зарегистрированных атаках на банки. Причём это были не внешние атаки, а именно внутренние, при которых злоумышленники получали удалённый доступ в корпоративную сеть банков и оттуда атаковали внутренние подсистемы.
На данный момент известно лишь то, что внутренней целью атаки стали АРМ КБР (автоматизированное рабочее место клиента Банка России), т.е. хосты, отвечающие за взаимодействие банка и Банка России. В итоге, злоумышленникам, вероятно, удалось получить доступ к электронной подписи банка и отправить от его имени поддельные распоряжения! Так как фактически распоряжения были верны, Банк России их обработал. Суммы хищений и количество пострадавших банков пока неизвестны.
Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных
Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных