Поделиться
ИТ-системы банков защищены гораздо хуже, чем принято считать
При тестировании банковского ПО методом "черного ящика" в защите каждой из трех проверяемых систем обнаружились серьезные бреши. Всего найдено 5 опасных типов уязвимостей, которые зачастую не учитываются разработчиками.Австрийская компания SEC Consult, специализирующаяся на вопросах ИТ-безопасности, при поддержке Cap Gemini провела тест на наличие уязвимостей в ПО, в том числе и в автоматизированных банковских системах (Core Banking System, CBS), используемых крупными банками. Кибератаки на банки постоянно учащаются, при этом их цели становятся все разнообразнее: от актов мести, саботажа, промышленного шпионажа до обычной кражи Причем хакеры уже давно проникают в глубь банковских систем не только через интернет, но и изнутри – через заражение компютеров сотрудников вредоносным ПО.
Чтобы прояснить ситуацию, компания SEC Consult на первом этапе исследования с помощью анкет опросила крупнейших производителей и поставщиков банковского ПО, причем все они охотно приняли участие в опросе. Был получен ожидаемый ответ: все поставщики используют новейшие технологии обеспечения безопасности. Большинство, по их собственным данным, внедрили также СМИБ (систему менеджмента информационной безопасности), соблюдают требования стандартов ISO/IEC 27001, а некоторые получили сертификаты соответствия этим стандартам. При этом большинство компаний указали, что располагают также современными моделями угроз для каждого модуля системы банковского ПО.
Огрехи разработки
Обеспечение безопасности процесса разработки с самого начала и при проведении рутинных операций требует наличия единой, структурированной методологии, о которой некоторые производители банковского ПО зачастую не заботятся. Поэтому компания SEC Consult считает процесс разработки программ, в которых встречается от 2 млн (Symbols компании SunGard) до 18 млн (Bankfusion Midas от компании Misys) строк программного кода, неудовлетворительным.
Что думают российские банки о защищенности своих ИТ-систем
Теоретически, как производители автомобилей перед выпуском модели проводят краш-тексты, так и разработчики должны тестировать ПО на предмет безопасности. У производителей есть возможность проверки методом "черного ящика", при котором тестировщики не имеют доступа к исходному коду и которое проводится специалистами вручную или автоматически. Кроме того, код сканируется на наличие проблем (Security Code Scan), и, наконец, желательно также, чтобы эксперты проверяли код вместе с динамической проверкой (Security Code Review). Некоторые из опрошенных компаний проводят такие тесты в полном объеме всеми тремя способами и для всех своих кодов, однако прочие либо почти совсем не тестируют свое ПО, либо тестируют не более половины написанного кода.
Без разрешения на атаку
Разумеется, производители прекрасно осознают, что их ПО уязвимо. Поэтому, несмотря на проявленный вначале интерес к исследованию, ни один из них не был готов выдать "разрешение на атаку", хотя компания SEC Consult и предложила им в качестве компенсации бесплатную проверку качества ПО. Из-за этого первоначальная цель – провести комплексное сравнение важнейших программ – не была достигнута. Но в конечном итоге три банка все же выразили заинтересованность в продолжении исследования и были готовы подвергнуть испытаниям внедренные у них автоматизированные банковские системы.
При этом банки использовали у себя в каждом случае один из обследованных на первом этапе продуктов, и, хотя речь не всегда шла о самой последней версии ПО, банки устанавливали все рекомендованные производителем обновления систем безопасности и должны были, если верить их поставщикам, находиться на самом высоком уровне обеспечения безопасности.
Испытания методом "черного ящика"
Итак, SEC Consult провела тестирование методом "черного ящика" (то есть без доступа к исходному коду), причем специалисты компании получили стандартный пользовательский аккаунт с минимальными правами, которые получает рядовой сотрудник банка. На каждый банк было потрачено около 20 человеко-часов, поэтому, с учетом миллионов строк кода, по оценкам SEC Consult, проверка затронула едва ли 1% функциональности программ.
Результаты оказались ошеломляющими. У всех программ были обнаружены серьезные недостатки защиты, что стало причиной нежелания компании SEC Consult сообщить, какие именно из названных программ (BankFusion Midas (Misys), Flexcube (Oracle), Avaloq (Avaloq), TCS Bancs (TCS Financial Solutions), Finacle (Infosys), Profile (Fidelity), Kordoba (Fidelity), Symbols (SunGard)) были фактически протестированы.
Пять серьезных проблем
Не претендуя на полноту данных, компания указала на 5 видов уязвимостей, обнаруженных в подвергнутых тестированию АБС.
Cross Site Scripting (XSS) – хищение персональных данных и шпионская деятельность в отношении пользователя, которым обычно является сотрудник банка. Сначала хакер пишет пользователю e-mail сообщение с "вредоносной" ссылкой, содержащей скрытый код сценария (скрипта). Если пользователь проходит по этой ссылке, скрипт запускается в его браузере, благодаря чему хакер получает возможность контролировать браузер, может фиксировать все действия пользователя и, в конечном итоге, делать все, на что у самого пользователя имеются права, в том числе – изменять реквизиты счетов, на которые выполняются переводы средств.
Privilege Escalation – повышение статуса пользователя: в проверяемых программах пользователям, имеющим минимальные привилегии, были доступны те же меню, что и пользователям с более широкими правами, но функции, к которым у них не было доступа, оставались для них невидимыми. С помощью простого изменения некоторых "параметров читаемого текста" (clear text parameters), которые браузер отправляет серверу, хакеры получали полный доступ к скрытым от них функциям.
Weak encryption – кража паролей: сначала хакер отслеживает движение данных между CBS-клиентом и CBS-сервером и, благодаря низкому уровню сложности пароля, получает возможность вскрыть механизм входа и перехватить аккаунт.
Standard Query Language (SQL) Injection – прямое считывание базы данных CBS. Атака осуществляется через плохо защищенные поля ввода данных и передаваемые параметры запросов, которые содержат, например, поисковые запросы или суммы в евро. В связи с недостаточной валидацией вводимой информации системой CBS, хакер может дополнить отсылаемый в базу данных запрос и извлечь данные, которые его интересуют.
Direct Operating System (OS) Command Execution – удаленное управление сервером CBS: хакер, используя уязвимость данного типа, загружает скрипт, который на этот раз содержит команду для операционной системы, благодаря чему хакер получает не доступ к базе данных, а контроль над операционной системой. Таким образом, он может по своему усмотрению управлять системой и даже завершать ее работу.
Компания SEC Consult порекомендовала банкам при приобретении программного обеспечения обращать особое внимание на то, чтобы их поставщики действительно осуществляли процессы разработки на современном уровне и проводили масштабное тестирование предлагаемой продукции. В любом случае должны быть незамедлительно приняты новые стандарты, поскольку, с точки зрения банка, соответствие нормативным требованиям всегда играет значимую роль при заключении контракта с поставщиком банковского ПО. Примечательно, что опрошенные CNews CIO банков утверждают, что инцидентов в сфере информационной безопасности АБС в их банках никогда не было.
Короткая ссылка
