В большинстве компаний используются модифицированные или разработанные самостоятельно бизнес-приложения. При этом чистота исходного кода никак не контролируется. В таких условиях ничто не мешает программисту-инсайдеру незаметно установить скрытую программную закладку, которая будет активирована в нужный момент. Отсюда возникает существенные риски, о которых говорить пока как-то не принято.
- Введение
- В чем смысл программных закладок?
- Расширения базового функционала
- Заказная разработка ПО
- Примеры использования программных закладок
- Чем можно защищаться?
- Выводы
- Комментарии экспертов
Введение
В наш век информационных технологий уже сложно представить какое-либо предприятие без компьютерного оборудования, на котором используется большое количество системного и прикладного программного обеспечения.
Как правило, если речь не идет об Open Source (ПО с открытым кодом), что стоит рассмотреть отдельно, на системном уровне от firmware до операционных систем и различных утилит, используется вполне стандартные приложения и заложенный в них производителем функционал. На этом уровне нужный функционал не создается индивидуально, а собирается подобно кирпичному дому из набора готовых программ и их модулей.
Что касается прикладного ПО, особенно бизнес-приложений, то здесь довольно часто требуется индивидуальная кастомизация для каждой компании, оптимальным образом изменяющая или расширяющая его базовый функционал. Каждая компания по-своему уникальна, поэтому эта уникальность и находит отражение в прикладном программном обеспечении. Например, большинство корпоративных CRM или ERP-систем индивидуально подстраиваются под конкретного заказчика, его бизнес-процессы и документооборот. Это же касается ПО для управления финансами предприятия, управленческого учета, программы автоматизации производства и т.п.
Часть уникальных для предприятия функций удается реализовать в рамках базового функционала стандартного бизнес-приложения путем изменения настроек. Но все же, во многих индустриях пользователям приходится дорабатывать стандартные бизнес-приложения (благо они позволяют это делать). Порой приходится даже разрабатывать их практически с нуля собственными силами или с помощью контрактных разработчиков. Особенно часто это происходит в сырьевых отраслях экономики (газ, нефть, металлургия), финансах (банки, страховые компании), энергетике, и сфере профессиональных услуг (транспорт, туризм). В силу специфики и необходимости интеграции с системами реального времени также самостоятельно или на заказ разрабатываются управляющие системы в наукоемких производствах, инновационных компаниях, медицине, образовании и т.п. Практически все государственные системы в России, начиная с масштабных федеральных ГАС Выборы, ЕГЭ и печально известной ЕГАИС, и заканчивая небольшими муниципальными системами создаются также на заказ.
Если за качество стандартных программ и бизнес-приложений своим именем отвечает производитель и при массовом использовании есть некий общественный контроль. Кроме того, многие популярные программы проходят сертификацию ФСТЭК и ФСБ РФ на отсутствие незадекларированных возможностей, что, хочется верить, также является дополнительным контролем их чистоты.
В этом смысле заказные или доработанные своими силами программы никак не контролируются. Для тех, кто их использует, они становятся чем-то вроде черного ящика, а что в нем происходит, знает только автор.
Таким образом, большинство компаний используют модифицированные или разработанные самостоятельно приложения, никак не контролируя чистоту исходного кода. О рисках связанных с тем мы расскажем в данном отчете.
В чем смысл программных закладок?
Удобным для нарушителя способом осуществления несанкционированного доступа к информации в компьютерных системах является метод алгоритмических и программных закладок.
Алгоритмическая закладка – это преднамеренное скрытое искажение части алгоритма программы, в результате чего возможно появление у программного компонента функций, не предусмотренных спецификацией и выполняющихся при определенных условиях протекания вычислительного процесса.
Программная закладка – это внесенные в программное обеспечение функциональные объекты, которые при определенных условиях (входных данных) инициируют выполнение не описанных в документации функций, позволяющих осуществлять несанкционированные воздействия на информацию (ГОСТ Р 51275-99).
Важно отметить, что внедрение и работа программной закладки в компьютере носит латентный характер. Ее работа может быть очень разноплановой, все зависит от фантазии программиста, писавшего программный «жучок». Программная закладка часто исполняет роль перехватчика паролей или трафика, служит для намеренного искажения передаваемой информации и даже нарушения непрерывности бизнеса (саботажа, т.е. злонамеренного вывода информационных систем из строя). Закладки часто существенно модифицируют данные в информационной системе, вплоть до ее уничтожения.
Таким образом, можно выделить следующие модели действий программных закладок:
1. перехват данных:
a. перехват вывода информации на экран;
b. перехват ввода с клавиатуры;
c. перехват и обработка файловых операций;
d. копирование и пересылка конфиденциальной пользовательской информации.
2. искажение данных:
a. неадекватная реакция на команды пользователя;
b. искажение передаваемой по сети информации;
c. блокирование принимаемой или передаваемой по сети информации;
d. изменение функционала самой программы.
3. уничтожение данных:
a. уничтожение конфиденциальной пользовательской информации;
b. инициирование программных и аппаратных сбоев.
4. получение несанкционированного доступа к данным:
a. получение управления некоторой функцией в обход системы авторизации;
b. получение доступа к данным и функциям извне разрешенного периметра.
Что касается бизнес-приложений, то здесь можно выделить два наиболее вероятных вектора атаки с точки зрения целевой установки программных закладок. Первый – это расширение и кастомизация имеющегося функционала программного обеспечения. Второй – заказные разработки силами внутренних или внешних специалистов. Давайте разберем эти два варианта более подробно.
Расширения базового функционала
Во многих случаях функционал стандартных бизнес-приложений может быть расширен с помощью встроенных языков программирования или макросов. Такие доработки функционала обычно ведутся сотрудниками компании, индивидуальными разработчиками или компаниями, специализирующимися на дополнительных разработках.
Хорошим примером здесь является российская программная платформа «1С Предприятие», которая в подавляющем большинстве случаев дорабатывается под конкретное предприятие и его бизнес-процессы. Существует множество типизированных отраслевых версий этого ПО, разрабатываемых партнерами 1С, а также тысячи частных программистов, имеющих свои наработки в области конкретной отраслевой экспертизы.
Другим примером является интегрированная автоматизированная система управления SAP R/3, в которой имеется проприетарный внутренний язык программирования высокого уровня ABAP/4. Этот встроенный язык реализует работу с внутренними структурами данных, интерфейсом пользователя SAP R/3 (транзакции и отчёты), работу с интерфейсами загрузки/выгрузки данных. Аналогичный по сути проприетарный внутренний язык программирования, называемый PeopleCode, используется в системах HRMS и CRM от Oracle (бывший PeopleSoft).
Для расширения или изменения базового функционала в более массовых бизнес-приложениях также используются специальные языки программирования. Например, к ним относится язык LotusScript, используемый в IBM Lotus Software, и VBScript, используемый в таких бизнес-приложениях как Microsoft Exchange Server. С помощью них может осуществляться доступ к данным в этих приложениях, а также различные операции с ними.
Наряду с гибкостью и удобством такой подход к улучшению функциональности привносит в информационную систему дополнительный риск. Принимая доработку, заказчик концентрируется на функционале, а не на безопасности, считая разработчиков заведомо честными и профессиональными. Как правило, код таких разработок никем не проверяется на наличие программных ошибок и незадекларированных возможностей (НДВ). Однако сами бизнес-приложения, работающие с персональными данными, в большинстве случаев проходят обязательную сертификацию во ФСТЭК и ФСБ.
Зачастую это связано с тем, что заказной аудит кода проходит долго и стоит дорого, а расширения бизнес-приложений запускаются в работу сразу после отладки. Поскольку большинство расширений бизнес-приложений реализуются на базе интерпретируемых языков, то становится возможным запускать на исполнение не только готовые программы с собственной логикой, но даже небольшие куски кода, вплоть до одной строчки.
Это приводит к тому, что программисты расширений для бизнес-приложений получают практически неконтролируемый кредит доверия в своих компаниях. Их работу никто ровным счетом не контролирует.
Заказная разработка ПО
Стоит отдельно рассмотреть случай, когда бизнес-приложения разрабатывают специально для конкретной компании, т.е. речь идет о заказной разработке. В этом случае клиент прибегает к услугам компаний, занимающихся заказными разработками, или же самостоятельно нанимает проектную команду разработчиков.
В любом случае заказчик, которым является лицо от бизнеса, не сможет толком даже проконтролировать качество разработанного ПО, не говоря уже про чистоту исходного кода. Дополнительный же наём экспертов на эту работу существенно увеличит бюджет проекта.
В итоге получается то же самое. Клиент получает в свое распоряжение некий черный ящик с отсутствие всяческих гарантий частоты исходного кода от недокументированных возможностей.
Если разработанное на заказ ПО будет использоваться в качестве информационных систем для обработки персональных данных (ИСПДн), то в соответствие с ФЗ №152 потребуется ее сертификация с обязательным предоставлением на экспертизу исходных кодов. Но даже в этом случае отсутствие НДВ вам будет гарантироваться лишь номинально. Не говоря уже про установленные в будущем всевозможные заплатки и обновления, частота которых никем точно не будет контролироваться.
Ну и последнее, на чем стоит остановиться в качестве примеров, иллюстрирующих масштаб и проникновении угрозы программных закладок – это просто огромное количество самых различных бизнес-приложений, написанных полностью или имеющих компоненты на языках Java и С# (основной язык разработки приложений для платформы Microsoft .NET). Особенность этих языков состоит в том, что исходного код программы транслируется в байт-код на стороне пользователя при помощи JVM или .NET Framework. Таким образом, в код программы может быть достаточно просто добавлена программная закладка.
Примеры использования программных закладок
С теорией вопроса мы разобрались, давайте теперь обратимся к практической части и рассмотрим реальные случаи обнаружения программных закладок в корпоративном ПО.
Следует заметить, что большинство закладок изначально устанавливается программистами не для противоправных действий, а для возможности быстро и без долгих бюрократических процедур внести изменения в уже работающую программу. Однако, если имеется возможность безнаказанно и неконтролируемо поставить закладку, некоторые программисты не в состоянии избежать искушения и использовать эту возможность для собственной выгоды и во вред компании.
Всего нами было обнаружено около 30 публичных случаем обнаружения программных закладок. В большинстве случаев закладки успешно использовались злоумышленниками и были обнаружены уже после активации. Однако в частных беседах руководители информационной безопасности компаний рассказывают про десятки примеров того, как намеренные или неосторожные действия программистов приводили к потере данных и прямым убыткам.
В России
В России наиболее известным случаем использования программных закладок является афера программиста ОАО "Акционерный капитал", реестродержателя акций ОАО «Татнефть», похитившего в 2005 году с помощью специально разработанного программного модуля 110 тысяч акций ОАО «Татнефть» на 5,7 млн руб и осужденного за это на пять с половиной лет (Источник).
Мошенники "одалживали" акции ОАО «Татнефть», снимая их со счетов, прокручивали на ММВБ, после чего возвращали, оставляя себе прибыль. Для этого в компьютерной программе Kapital, проводящей операции с ценными бумагами, программист-инсайдер создал специальную папку. В ней был файл-модуль с функцией Take CB. Она выбирала из базы данных владельцев акций "Татнефти" физических лиц, имевших не меньше 300 акций. Затем со счета каждого из них она переводила по 100 акций на свои счета. Затем ценные бумаги перемещались на ММВБ. Доходы, полученные от операций на бирже, перечислялись на карточные счета в казанском филиале банка "Зенит". Эти счета были также зарегистрированы на подставных лиц, которые снимали с них деньги и передавали мошенникам.
Основной задачей изобретения программиста-инсайдера было ввести в заблуждение компьютерную систему реестродержателя, чтобы она не могла заметить исчезновения акций со счетов законных владельцев. Его программа работала так, что после похищения ценных бумаг на счету акционера появлялся знак "минус". Когда же акции после операций на ММВБ возвращались на место, этот знак исчезал. А компьютерная система ОАО "Акционерный капитал" была создана таким образом, что реагировала только на положительные цифры.
Совсем недавно была обнародована информация об очередном случае внедрения программной закладки в программное обеспечение. Следствие установило, что некто г-н Жуков создал компьютерную программу «Расчет заработной платы», при этом умышленно дополнил программный код вредоносными алгоритмами. Эта программа пользовалась популярностью среди пользователей ввиду ее простоты и удобства, и поэтому получила широкое распространение в организациях Магадана и области. Вредоносные свойства программы начинали проявляться через определенное время у тех пользователей, которые приобрели программу без заключения договора на ее обслуживание и установление обновлений за дополнительную плату. В программе блокировались пункты главного меню, имитировались сбои, при составлении отчетов выдавалась недостоверная информация. Одновременно на экране появлялись сообщения о необходимости обратиться к разработчику, который в свою очередь предлагал пользователю дополнительно оплатить его услуги. В итоге пользователь был вынужден либо отказаться от использования данной программы, либо постоянно платить за ее обслуживание, что было выгодно автору программы и повышало рентабельность его бизнеса.
Приведем еще один пример атаки защищенной системы программной закладкой из отечественной практики (источник). Служба безопасности одной из фирм, занимающихся посреднической деятельностью, обнаружила, что конфиденциальная информация, передаваемая партнерам по электронной почте, становится известной третьей стороне, несмотря на то, что в системе использовались платы “Криптон” (продукция фирмы Анкад), реализующие обеспечивающий гарантированную защиту информации алгоритм шифрования в соответствии с ГОСТ 28147-89.
Спустя некоторое время во всех компьютерах фирмы, на которых стояла указанная плата, была выявлена одна и та же программная закладка. Она попросту отключала плату “Криптон-3” и брала ее функции на себя, причем для шифрования данных вместо алгоритма по указанному ГОСТ использовался другой, совершенно нестойкий алгоритм. Проведенное расследование показало, что за несколько недель до описываемых событий во все отделения фирмы от лица якобы производителя платы “Криптон-3” пришли письма, к которым была приложена программа, о которой в письме говорилось, что это бесплатно распространяемый драйвер “Турбо Криптон”, повышающий быстродействие платы в несколько десятков раз. Не заметив подвоха, сетевые администраторы немедленно установили присланный драйвер на все соответствующие компьютеры, в результате чего скорость шифрования действительно возросла, но защита электронной почты фактически отключилась.
В мире
Самым ярким примером действия программной закладки является военный конфликт в Персидском заливе. Тогда при проведении операции «Буря в пустыне» система ПВО Ирака оказалась заблокированной по неизвестной причине. Несмотря на отсутствие исчерпывающей информации, высказывалось предположение, что ЭВМ, входящие в состав комплекса технических средств системы ПВО, закупленные Ираком у Франции, содержали специальные управляемые «электронные закладки», блокировавшие работу вычислительной системы.
Периодически эксперты обнаруживают недокументированных возможности в ПО для аппаратных комплексов. Например, в информационном бюллетене CERT CA-2002-32 объявлено о существовании программной закладки (backdoor) в операционной системе AOS (Alcatel Operating System) версии 5.1.1, применяемой для управления коммутаторами Alcatel OmniSwitch 7700/7800. Эта закладка запускает telnet-сервис на порту 6778/TCP, что может позволить удаленному злоумышленнику неавторизованно управлять коммутатором.
Есть случаи, когда уволенный программист похитил данные через оставленный собой же «черный ход» (backdoor) в программе. Что написанная программа перед запуском проверяла наличие своего разработчика в зарплатных списках и однажды, не найдя его там, уничтожила данные.
Что касается серьезных бизнес-приложений, например, SAP, то здесь пока публично неизвестно о случаях внедрения программных закладок и их использования. Однако экспертное сообщество всполошил доклад SAP Backdoors, сделанный компанией Onapsis на конференции BlackHat USA 2010. В нем рассказывается по крайней мере о четырех путях внедрения программных закладок в инсталляции продуктов компании SAP.
Чем можно защищаться?
Принципиально можно выделить два направления защиты от программных закладок: организационный и технический. Рассмотрим их немного подробнее.
Организационный способ защиты
Привычный и всем понятный организационный подход к защите чаще всего применяется в крупных компаниях, ведущих собственные дополнительные разработки к крупным приложениям, чаще всего это ERP или АБС. Ключевым моментом этого подхода является разделение жизненного цикла продукта на три этапа: разработка, тестирование и непосредственное использование.
На первом этапе пишется код, на втором тестируется корректность реализации функционала и наличие ошибок, в том числе и с точки зрения безопасности (всевозможные тесты на проникновение). На обоих этапах хорошей практикой является привлечение в проектную команду консультантов по безопасности. После положительного заключения тестировщиков программное обеспечение передается во внедрение.
Таким образом, достигается разделение разработки, контроля качества и пользователей программного обеспечения. В результате вероятность успешной незаметной установки и последующего использования программной закладки серьезно падает. Кроме того, для проведения успешной аферы нужно будет вовлечь в преступный сговор сотрудников на нескольких этапах, что может быть очень рискованно.
Технический способ защиты
Помимо организационного подхода существует и технический, когда разработанное самостоятельно или на заказ программное обеспечение отдается на аудит кода внешним экспертам, которые специализируется на подобных услугах. Это происходит чаще всего в тех случаях, когда разработку заказывают у третьей компании.
В качестве технических средств для поиска программных закладок могут использоваться сканеры кода, которые способны по определенным алгоритмам обнаруживать подозрительные куски кода.
Кроме этого, для обнаружения закладок могут использоваться тестовые среды и анализаторы потенциальных уязвимостей. Например, для SAP R/3 подобные технические средства и услуги предоставляют компания Onapsis и Virtual Forge, которые используют статический и динамический анализ кода.
До недавнего времени практически не было продуктов, которые бы доступны по цене и функционалу компаниям, разрабатывающим продукт для собственных нужд. С приходом в аудит кода технологий, прежде принятых в DLP-продуктах (лингвистический анализ и «цифровые отпечатки») стал возможен статический анализ кода на совпадение с шаблонами известных уязвимостей и закладок «на лету». Плюс этого метода в оперативности (код анализируется практически мгновенно и вне зависимости от логики программы) и отсутствия необходимости запуска программы на исполнение. Анализировать можно как готовые программы, так и произвольные куски кода, вплоть до одной строчки. Минусом является необходимость постоянного пополнения базы известных уязвимостей (с каждой уязвимости снимается уникальный отпечаток, который затем сравнивается с отпечатками нормализованного текста программы).
Такой анализ дает возможность сотрудникам, ответственным за безопасность и качество продуктов без привлечения сторонних аудиторов кода находить и обезвреживать часто встречающиеся закладки, типа обхода тестовой среды («если среда тестовая, то эту функцию не запускать»), вход в систему в обход авторизации, опасные манипуляции с критическими данными и другие. Одной из самых востребованных функций здесь является «поиск подобного», которая позволяет при обнаружении специфической закладки проверить наличие подобных операций во всем коде приложения.
Пионером в реализации данного подхода к анализу кода стала молодая компания Appercut, которая предлагает клиентам статический анализ кода бизнес-приложений, которые разрабатываются компаниями самостоятельно. Ее продукты дают возможность контролировать код приложений до их запуска на исполнение и существенно экономить на внешних аудитах кода.
Продукт реализован в виде веб-сервиса, однако сервер анализа можно поставить и вовнутрь информационной системы компании. Отпечатки уязвимостей пополняются ежеквартально, при этом у пользователей есть возможность добавлять собственные, специфические для их информационной системы уязвимости. Эта функция особенно важна, поскольку часть опасного кода использует не специфику языка программирования, а особенности архитектуры приложения или особенности бизнес-процесса, реализованного в приложении.
Выводы
По данным Informit рынок безопасности приложений (Software Security) растет быстрыми темпами, составив в 2009 году 550 млн. долларов США. Его большую часть составляют услуги, а также продажи web- и application- фаерволов, но около 25% составляют продажи продуктов по аудиту кода (Code Review Tools). Причем этот сегмент растет наибольшими темпами.
Пока что большинство продуктов по аудиту кода ориентированы на профессиональных пользователей. Однако с приходом на этот рынок производителей, обладающих DLP-технологиями, такие продукты могут стать доступны клиентам, которые разрабатывают продукты для автоматизации собственных бизнес-процессов.
Производители DLP-продуктов могут привнести на этот рынок не только технологии, но и методологию борьбы с инсайдерами, ведь программисты, злонамеренно модифицирующие код, по сути, являются теми же инсайдерами.
Комментарии экспертов
Ринат Гимранов, Руководитель Управления ИТ ОАО «Сургутнефтегаз»:
«Сам принцип многократного использования программного кода, не так давно усиленный возможностями сервис-ориентированной архитектуры, делает вопросы безопасности прикладного программного обеспечения очень важным звеном в системе обеспечения информационной безопасности предприятия.
В проектах внедрения и развития информационной системы крупного предприятия, например, на базе систем SAP, количество изменяемых в месяц программ измеряется тысячами. Это - разработки и доработки десятков собственных программистов, результаты заказной работы консультантов, обновления в купленные готовыми программные комплексы, изменения от SAP в рамках сопровождения и оптимизации.
Одна несанкционированная проводка может свести на нет все усилия по обеспечению информационной защиты от несанкционированного доступа, от порчи и потери данных и программ или от других подобных действий. Обеспечить реальный контроль безопасности изменений в программный код (особенно от несанкционированных бизнес-действий) можно только в автоматизированном режиме, так что меня радует появление инструментов - анализаторов кода, которые, так же как и другие решения по информационной безопасности, должны создаваться командами, независимыми от производителей ПО и консалтинговых компаний».
Рустем Хайрединов, представитель Appercut в регионе ЕМЕА:
«Наличие проблемы контроля кода при разработке проприетарных бизнес-приложений признают большинство крупных компаний. Крупные компании содержат иногда сотни программистов, постоянно дорабатывающих ERP системы, ABS, CRM и другие бизнес-приложения. Но это проблема не только крупных компаний - даже в самых маленьких компаниях существуют свои или приходящие программисты 1С, постоянно добавляющие в систему новые отчеты или другие функции. Что они добавляют, кроме заявленного функционала, никто не проверяет, а роль бизнес-приложений такова, что ошибка или закладка может привести к потере не только данных, но и денег, что хорошо показано в отчете.
Классические сканеры приложений хорошо справляются с поставленной им задачей – поиском критических уязвимостей в коде приложений, у их разработчиков накоплен колоссальный опыт поиска уязвимостей. Но у бизнес-приложений есть и своя специфика: существенная часть уязвимостей безупречна с точки зрения языка, но использует специфику архитектуры приложения или особенности бизнес процесса. Например, ни один существующий сканер не признает ошибкой в коде ABS изменение номера банковского счета клиента в обход процедуры, а опасность такой операции в коде - очевидна. С точки зрения программирования команда на одновременную блокировку двигателей всех автомобилей, защищенных спутниковой сигнализацией не является подозрительной, а с точки зрения бизнеса – может привести к непоправимым последствиям. Никто, кроме самого заказчика разработки не знает функционал и архитектуру приложения лучше него, поэтому в дополнение к существующим на рынке сканерам и сервисам, заказчику нужен инструмент контроля своих собственных разработок, который можно самостоятельно или с помощью сторонних консультантов обучать на обнаружение специфических для бизнес-приложения уязвимостей.
Для такого компенсирующего контроля DLP-технологии накопили существенную технологическую экспертизу. Ведь код программы – это специфический плоский текст, а сравнивать тексты с образцами и искать в тексте даже сильно измененные цитаты умеют большинство DLP-продуктов. Неотъемлемой частью любой DLP-технологии является ее самообучаемость, а значит, чем больше пользователь использует продукт, тем эффективнее он справляется с поставленной задачей».
Алексей Лукацкий, Менеджер по развитию бизнеса Cisco Systems:
«Поднятая в статье проблема не просто актуальна для современного рынка; она крайне важна и до недавнего времени практически никак не решалась. Ведь безопасность исторически решалась на самом нижнем уровне – уровне данных, когда никто не знал, что реально должно защищаться. Защищались пакеты в сети, файлы на компьютере, приложения на серверах, но мало кто из производителей задумывался о защите реальной информации, участвующей в принятии управленческих решений и имеющей реальную стоимость для бизнеса. И чем дальше, тем ситуация становилась хуже.
Если единичные производители (и то на Западе) стали предлагать решения для защиты стандартных пакетов прикладных систем, то почти никто не предлагал решения по защите самописного кода. Если же такие предложения и были, то были очень дорогими и предлагались в форме заказных услуг, а не отдельно продаваемых продуктов. В статье описано новое решение, которое устраняет этот пробел и позволяет потребителям наконец-то получить механизм, удостоверяющий отсутствие случайных ошибок или специально внесенных закладок в собственном программном коде».
