Анализ уязвимостей автоматизированных систем управления технологическими процессами

Размещено на http://www.allbest.ru/

Федеральное агентство связи

Федеральное государственное бюджетное образовательное учреждение высшего образования

«Поволжский государственный университет телекоммуникаций и информатики»

ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА

Анализ уязвимостей автоматизированных систем управления технологическими процессами (лабораторная работа)

А.Ю. Молочко

Самара 2017

Реферат

Название	Анализ уязвимостей автоматизированных систем управления технологическими процессами (лабораторная работа).
Автор	Молочко Анастасия Юрьевна
Научный руководитель	Раков Александр Сергеевич
Ключевые слова	АСУ ТП, уязвимость, информационная безопасность, SCADA-система.
Дата публикации	2017
Библиографическое описание	Молочко А.Ю. Анализ уязвимостей автоматизированных систем управления технологическими процессами (лабораторная работа): дипломная работа / А.Ю. Молочко. Поволжский государственный университет телекоммуникаций и информатики (ПГУТИ). Факультет телекоммуникаций и радиотехники (ФТР). Кафедра мультисервисных сетей и информационной безопасности (МСИБ): науч. рук. А.С. Раков - Самара. 2017. - 92 с.
Аннотация	В данной дипломной работе были рассмотрены и описаны проблемы безопасности АСУ ТП. Проведен анализ известных атак на АСУ ТП и приведено описание различных производителей SCADA систем. Рассмотрено описание и типы конвертера Ethenet->RS-232. Проведен эксперимент по настройке и реализации АСУ ТП и проверке системы на уязвимости. Выработаны рекомендации по устранению уязвимостей.

Содержание

Введение

1. Проблемы безопасности АСУ ТП

1.1 Степень риска обнаруженных уязвимостей

2. Анализ известных атак на АСУ ТП

2.1 Stuxnet

2.2 Duqu

2.3 Flame

3. Производители SCADA систем

3.1 Master SCADA

3.2 SCADA TRACE MODE

3.3 SIMP Light miniSCADA

3.4 SIMATIC WinCC

3.5 SCADA система Citect

3.6 SCADA система Intouch

3.7 PcVue Solutions

4. Конвертор Ethernet-> RS-232

4.1 Типы преобразователей интерфейсов

4.2 Преобразователь интерфейса Ethernet-RS-232/RS-485 ЕКОН131

5. Экспериментальная часть

5.1 Оборудование

5.2 Программное обеспечение

5.3 Настройка стенда

5.4 Проверка работоспособности

5.5 Тестирование защищенности АСУ ТП

6. Методические указания

6.1 Состав лабораторного стенда

6.2 Краткое описание работы стенда

6.3 Порядок выполнения работы

Заключение

Введение

В век информационных технологий, когда в каждом доме, офисе и предприятии большая часть ручного и умственного труда заменяется автоматизированными системами. Появляется проблема безопасности этих систем. Долгие годы люди акцент в защите информации делался на «классические» информационно-телекоммуникационные системы, но начиная с 2010-2011 годов, внимание специалистов по информационной безопасности начало смещаться на сегмент автоматизированных систем управления технологическими процессами (АСУ ТП). Это произошло в силу ряда успешных и очень опасных действий со стороны разрушающего программного воздействия и программных закладок, в частности. Системы АСУ ТП относятся к критически важной инфраструктуре, проблемы с которой могут, с высокой степенью вероятности, повлечь большие материальны, экологические и человеческие жертвы.

Несмотря на важность темы, ее рассмотрение никак не затрагивается не только у нас в ВУЗе, но и в большинстве других, не являющихся специализированными по АСУ ТП. Причиной этого вероятно можно назвать стоимость компонентов типовой АСУ ТП.

С учетом этого стоит отметить выгодное положение на рынке универсальных и учебных контроллеров, например, Arduino и появление бесплатных и доступных для быстрого изучения систем АСУ ТП. Все это позволяет предложить разработку небольшой, но полноценной АСУ ТП, для целей тестирования ее защищенности.

Все вышесказанное подтверждает актуальность темы работы - «Анализ уязвимостей автоматизированных систем управления технологическими процессами (АСУ ТП)» (Лабораторная работа).

Целью дипломной работы является разработка и настройка стенда по лабораторной работе «Анализ уязвимостей АСУ ТП». Для достижения поставленной цели необходимо решить следующие основные задачи:

· рассмотреть проблемы безопасности АСУ ТП;

· проанализировать известные атаки на АСУ ТП;

· сравнить производителей SCADA систем, с целью выбора системы для лабораторного стенда;

· рассмотреть типы конвертеров, особое внимание, уделив преобразователям Ethernet->RS-232;

· собрать и настроить лабораторный стенд;

· провести тестирование и анализ уязвимостей в рамках лабораторного стенда;

· оформить макет методического пособия.

Объектом исследования выступает доступная реализация АСУ ТП в виде лабораторного стенда.

Предметом исследования является АСУ ТП.

Основными источниками информации для написания работы послужили Приказ ФСТЭК России от 14 марта 2014 г. N 31, интернет-статьи, такие как Б.Н. Пищик Безопасность АСУ ТП// СТА 2013г., сайты Хабрахабр и Хакер.

Цель и задачи написания работы определили ее структуру, которая состоит из введения, 5 глав, заключения, списка используемых источников и приложений.

Во введении обосновывается актуальность работы, цель, задачи, объект и предмет исследования.

Первая глава раскрывает проблемы безопасности АСУ ТП, причем по большей части недостатков безопасности виноваты сотрудники предприятия.

Вторая глава дает обзор по самым известным и опасным вирусам.

Третья глава раскрывает разнообразие SCADA систем, а также характеристики каждой системы и сравнение их между собой.

Четвертая глава содержит в себе описание типов преобразователей, и особое внимание уделяется конвертеру Ethernet->RS-232.

Пятая глава содержит в себе экспериментальная часть, где в полной мере описана работа над сбором и настройкой оборудования, а также результаты сканирования на уязвимости.

В заключении сделаны основные выводы и результаты по проделанной работе.

1. Проблемы безопасности АСУ ТП

Изучение структуры и используемых программно-аппаратных средств современных АСУ ТП показало, что за последнее время произошли существенные изменения. Повсеместно используется широко распространенное системное программное обеспечение (ПО): ОС Windows, TCP/IP протоколы и т. п., которые вместе со своими достоинствами принесли и свои недостатки -- уязвимости. Нередко в сети АСУ ТП появляются компьютеры, имеющие доступ в Интернет.

Атаки на промышленные системы проводятся с помощью программных средств, разработанных не только хакерами-одиночками (внешними, а чаще внутренними пользователями систем), но и организованными группами высококвалифицированных специалистов. Так, специалисты по информационной безопасности, анализирующие Stuxnet (Stuxnet), отмечают, что данный вирус содержал целевой код, удовлетворяющий целому ряду специфических требований и реализующий полноценную атаку на системы АСУ ТП производства компании Siemens.

В частности, для реализации потенциала нападения вирус требовал наличия частотных конверторов производства двух компаний -- Vacon (Финляндия) и Fararo Paya (Иран), работающих на частотах от 807 до 1210 Гц. Наличие подобных требований позволило большинству экспертов, исследовавших данный код, сделать вывод о том, что вирус предназначался для точечной атаки вполне определённого производства или ряда производств. Согласно анализу, проведённому специалистами компании Symantec, вредоносный код Stuxnetа реализовывал атаку сразу на нескольких уровнях: на уровне операционных систем Windows, ПО управления АСУ ТП Siemens WinCC/PCS 7 и непосредственно программируемых логических контроллеров (ПЛК) Siemens S7-300, обслуживающих конверторы частоты (которые, в свою очередь, управляли скоростью вращения электромоторов).

По данным компании Siemens, из 15 случаев заражения вирусом в Германии ни в одном случае не было проникновения в ПЛК, так как не совпали параметры, в то время как на иранских объектах это удалось. Таким образом, атака была тщательно подготовлена специалистами, имеющими весьма специальные знания об объектах атаки. Это позволяет сделать предположение об организованной и спланированной акции, что не похоже на действия злоумышленников-одиночек.

Появился даже новый термин -- “кибервойна” (cyberwarfare), упоминаемый в СМИ в связи проблемой защиты систем АСУ ТП на инфраструктурных объектах и опасных производствах. В ряде стран (например, в США и Китае) созданы специализированные подразделения для выведения из строя инфраструктуры на стороне потенциального противника. Так, в Ираке была дистанционно выведена из строя система радиолокационного обнаружения воздушных целей.

Таким образом, повсеместное использование компьютерного оборудования в управлении промышленными предприятиями выдвигает и повышенные требования к информационной безопасности (ИБ) таких систем.

Обзор состояния безопасности АСУ ТП, проведённый компанией Positive Technologies в 2012 г., показал довольно тревожную картину. Резко увеличивается число обнаруженных уязвимостей. С 2010 по 2012 г. установлено в 20 раз больше уязвимостей, чем за предыдущие 5 лет. Каждая пятая уязвимость устраняется дольше месяца. 50 % уязвимостей позволяют хакеру запустить выполнение кода.

Для 35 % уязвимостей есть эксплойты. Более 40 % доступных в Интернет систем могут взломать хакеры-любители. Больше всего уязвимостей обнаруживается у известных производителей: Siemens 42, Schneider Electric 30, Advantech/Broadwin 22, Invensys Wonderware 15, General Electric 15 [1].

Как правило, количество опубликованных уязвимостей коррелирует с количеством опубликованных эксплойтов. В период с начала 2011 года по сентябрь 2012 года было опубликовано 50 эксплойтов -- в шесть раз больше, чем за шесть лет с 2005-го по 2010 год (см. рис. 1.1).

Рис. 1.1 - Количество опубликованных эксплойтов

Относительно небольшое количество эксплойтов, появившихся в 2012 году, объясняется двумя факторами:

· упорядочиванием взаимоотношений между производителями АСУ ТП и исследователями, политика ответственного разглашения;

· традиционной задержкой между публикацией уязвимости и выходом эксплойта (его разработка требует дополнительных затрат).

1.1 Степень риска обнаруженных уязвимостей

Почти 65% всех уязвимостей относятся к высокой (значение CVSS v. 2 Base Score > 6,5) или критической степени риска (доступен эксплойт) (см. рис. 1.2).

Рис. 1.2 - Степени риска обнаруженных уязвимостей

Впрочем, отсутствие известного способа реализации атаки снижает вероятность нападения, но не исключает его полностью, поскольку кибератаки на промышленные объекты проводятся с привлечением опытных специалистов высокого уровня, которым зачастую попросту не нужны «эксплойт-паки» и прочие популярные инструменты [2].

Что касается стран, то доли уязвимых АСУ ТП (обеспечивающих доступ к АСУ ТП из Интернет) составили: Швейцария 100 %, Чешская республика 86 %, Швеция 67 %, Великобритания 60 %, Россия 50 %, США 41 %, Германия 20 %.

Нельзя сказать, что разработчики АСУ ТП совсем не уделяют внимания информационной безопасности.

Основные проблемы информационной безопасности АСУТП, выделяемые экспертами, проистекают:

-- из слабой защиты от несанкционированного доступа (пароли);

-- не декларированных возможностей SCADA;

-- отсутствия контроля управляющих воздействий (совокупность параметров);

-- использования беспроводных коммуникаций (некриптостойкое шифрование WiFi);

-- отсутствия чётких границ между разными частями сети;

-- несвоевременного или некорректного обновления программного обеспечения;

-- дистанционных методов управления;

-- Веб-технологий, используемых на верхнем уровне АСУ ТП;

-- отказа даже от минимальных мер безопасности (нередко ради удобства и производительности, компании отказываются от установки не только, например, антивирусной, но и даже парольной защиты критически важных активов);

-- распространения Windows в качестве основной операционной системы для рабочих станций и даже для серверов;

-- разработки в расчёте на выполнение в доверенной среде закрытых индустриальных сетей;

-- создания систем без учёта лучших практик разработки безопасного кода;

-- человеческого фактора -- слабой дисциплины сотрудников.

Типичная АСУ ТП имеет от двух до трёх уровней сетевой архитектуры. На современных предприятиях всё чаще реализуется единая среда управления в корпоративной сети, в которой размещены компьютеры и системы, посредством которых осуществляется управление организационной и финансовой деятельностью. Часть компьютеров этой сети может иметь доступ к серверам АСУ ТП, содержащим накапливаемую о технологическом процессе информацию.

Сеть собственно АСУ ТП может иметь верхний уровень (станции операторов и инженеров АСУ ТП, серверы баз данных, серверы приложений), средний уровень (программируемые логические контроллеры) и нижний уровень (датчики сбора данных и исполнительные механизмы). Связь между уровнями обеспечивается коммуникационными серверами или контроллерами. Доступ к датчикам осуществляется по протоколам и полевым шинам (RS485, RS232, Fieldbus, ProfiBus, CAN, OPC и др.).

Современной тенденцией является использование IP и Ethernet сетей на верхнем и среднем уровнях. Всё чаще промышленные устройства имеют Ethernet порты и IP протоколы, которые используются на всех уровнях сети АСУ ТП.

Таким образом, особенностью сетей АСУ ТП является использование в дополнение к IP ещё и специализированных протоколов, которые если и затрудняют проникновение, то, как показывают инциденты, не для профессионалов. Следует отметить, что соединение по специальным протоколам, как правило, не предусматривает средств защиты.

Приведём перечень основных угроз АСУ ТП, отмеченных в реальных инцидентах:

-- атаки на SCADA;

-- атаки на PLC, уязвимости PLC (пароль по умолчанию, неавторизованный доступ к фирменному программному обеспечению, удалённое изменение пароля и т. д.);

-- атаки на инфраструктуру и оперативную систему (вирусы, троянские программы, черви, DoS- и DDos-атаки, ARP-спуфинг -- перехват трафика после объявления себя маршрутизатором);

-- атаки на протоколы, уязвимость протоколов (OPC -- переполнение буфера, нестойкий пароль -- 2011 г.);

-- атаки баз данных (несанкционированный доступ, SQL инъекция);

-- практические атаки (переполнение буфера -- Buffer Overflow, раскрытие информации -- Information Disclose, отказ в доступе -- Denial of Access, отказ в управлении -- Denial of control, отказ в представлении -- Denial of view, подмена представления -- Manipulation of View).

Среди всех типов уязвимых компонентов АСУ ТП лидируют SCADA -- 87 %, далее следуют системы, обеспечивающие человеко-машинные интерфейсы (HMI), -- 49 %, реже обнаруживаются уязвимости в программируемых контроллерах -- 20 % и совсем редко в используемых протоколах -- 1 %.

Доли уязвимостей по типам распределились следующим образом: переполнение буфера 36 %, аутентификация/управление ключами 22,86 %, уязвимости веб-приложений (сервер 10,86 %, клиент 9,14 %), удаленное исполнение кода 13,14 %.

Вследствие длительности эксплуатации АСУ ТП (разработка и эксплуатация могут составлять более десяти лет) и существенного изменения состава и качества современных угроз необходимо проектировать и реализовывать информационную безопасность систем с учётом тенденций развития киберугроз. С другой стороны, необходимо проводить регулярную работу по нейтрализации возникающих или потенциальных угроз на работающих системах.

Совокупность нейтрализующих мер можно разделить на две группы: административно-организационные и программно-технические.

Первая группа мер связана с формированием программы работ по обеспечению ИБ АСУ ТП и разработкой набора документов, которые регламентируют высокоуровневый подход по обеспечению ИБ, а также описывают политику развития системы ИБ АСУ ТП. Кроме того, формируется пакет организационной документации, направленной на создание и поддержание режима ИБ АСУ ТП.

Программно-технические меры образуют основной набор средств обеспечения ИБ АСУ ТП. На этом уровне реализуются следующие сервисы ИБ: управление доступом, обеспечение целостности, обеспечение безопасного межсетевого взаимодействия, антивирусная защита, анализ защищённости, обнаружение вторжений, управление системой ИБ (непрерывный мониторинг состояния, выявление инцидентов, реагирование). Конкретные требования к перечисленным сервисам предъявляются на основании анализа обрабатываемой информации и оценки угроз безопасности АСУ ТП.

Каждая группа мер в зависимости от необходимости и возможностей предприятия может осуществляться на одном из трёх уровней. Базовый уровень включает механизмы, традиционные для большинства информационных систем. Средний уровень предполагает выполнение начальных тактических мероприятий, обеспечивающих реализацию управляемых защитных функций по обеспечению ИБ. На расширенном (высоком) уровне реализуются мероприятия, поддерживающие и расширяющие базовый и средний уровень, но для их реализации может потребоваться дополнительная экспертиза.

Так, для первой группы мер на базовом уровне предполагается разработка документов, описывающих политику кибербезопасности, внедрение политик и процедур из государственных стандартов по безопасности критически важных объектов. На среднем уровне ведутся работы по внедрению лучших индустриальных практик, осуществляется контроль выполнения политик и процедур. На расширенном уровне внедряется процесс непрерывного улучшения политик и процедур ИБ, периодически проводится обучение и аудит. Для иллюстрации разных уровней второй группы мер рассмотрим сервис обеспечения безопасного межсетевого взаимодействия.

На базовом уровне требуется внедрение электронного периметра и отключение всех необязательных для основного процесса соединений. Составляется и поддерживается в актуальном состоянии список критических объектов. На среднем уровне электронный периметр разделяется на зоны: ЛВС АСУ ТП, демилитаризованная зона и зона корпоративной ЛВС. Анализируется и минимизируется количество ресурсов, доступных одновременно из сети АСУ ТП и сети корпоративной ЛВС. Поставщики оборудования и интеграторы периодически проводят обучение сотрудников. Так, схема зонирования в архитектуре Cisco SAFE for PCN (Process Control Network) разделена на 6 уровней.

Зона ЛВС АСУ ТП (уровень 0 -- уровень 3) отделяет критичные системы АСУ ТП и состоит из нескольких функциональных минизон. Нулевой уровень -- датчики сбора данных и исполнительные механизмы. Первый уровень -- узлы коммутации, обеспечивающие подключение датчиков к ПЛК. Второй-третий уровень -- ПЛК, рабочие места операторов, серверы хранения данных. Могут использоваться межсетевые экраны и IDS.

Демилитаризованная зона обеспечивает связность корпоративной ЛВС и ЛВС АСУ ТП. Она содержит только некритичные системы, которым необходим доступ к корпоративной ЛВС и ЛВС АСУ ТП, состоит из нескольких функциональных мини зон и отделена межсетевыми экранами и IPS. Зона корпоративной ЛВС содержит типичные бизнес-приложения: почта, АСУП (четвертый уровень), Интернет (пятый уровень).

На расширенном уровне осуществляется внедрение VLAN, PVLAN, NIPS/HIPS, средств обнаружения аномалий и вторжений, интеллектуальных коммутаторов и т. п.

В области защиты систем управления (ControlSystems, SCADA) в настоящий момент существует целый ряд стандартов и рекомендаций. Их можно классифицировать следующим образом:

1) отраслевые решения:

-- стандарты NERC для систем управления электрическими сетями;

-- стандарты ChemITC для химической индустрии;

-- Cisco SAFE for PCN -- стандарты Газпрома.

2) рекомендации общего уровня (стандарты NIST, ISA и др.):

-- ISA S99 -- Комитет общества приборостроения, системотехники и автоматизации (ISA);

-- NIST PCSRF Security Capabilities Profile for Industrial Control Systems;

-- IEC 61784-4;

-- КСИИ ФСТЭК.

При этом каких-либо обязательных требований к соответствию определенным критериям безопасности для коммерческих компаний не предъявляется.

Процесс с выпуском российских стандартов по информационной безопасности АСУ ТП явно затягивается, и, таким образом, сохраняется некоторая неопределённость для интеграторов и ИТ структур, обеспечивающих безопасность АСУ ТП [1].

2. Анализ известных атак на АСУ ТП

2.1 Stuxnet

Кросс-платформенный червь Stuxnet был обнаружен в июле 2010 г.. Он нацелен на промышленные системы управления для того, чтобы брать под свой контроль промышленные объекты, таких как электростанции. Хотя точные мотивы атакующего для этого неясны, было предположение, что это может быть по ряду причин с наиболее вероятным намерением являющегося промышленным шпионажем.

Отличительные особенности:

· Stuxnet содержит несколько модулей, написанных с использованием нескольких сред разработки и языков программирования;

· для обхода механизмов антивирусной защиты некоторые модули (драйверы) ВПО имели цифровую подпись, сделанную с использованием сертификатов компаний Realtek и JMicron (предположительно, украденных);

· несколько способов распространения - посредством USB-флэш накопителей и по сети. В версии 2009 года использовался широко применяемый способ запуска через autorun.inf (который, как правило, отключают из соображений безопасности), в версии 2010 года он был заменен на более эффективный - использование уязвимости обработки ярлыков MS10-046 (zero-day на тот момент). Для распространения через сеть использовались уязвимости MS08-067 (ранее использовалась в 2009 году ВПО Kido, что привело к массовым заражениям) и MS10-061 (zero-day на тот момент);

· для обеспечения работы производилось повышение привилегий до уровня администратора системы при помощи использования двух локальных уязвимостей (zero-day на тот момент) MS10-073 (Windows 2000 и XP) и MS10-092 (Windows Vista, включая версию x64), таким образом, было предусмотрен нормальный запуск ВПО из-под ограниченных учетных записей;

· Stuxnet организует свою собственную peer-to-peer (P2P) сеть для синхронизации и обновления своих копий;

· присутствует функционал, позволяющий пересылать на удаленные сервера управления информацию, найденную на компьютере;

· необычная «полезная» нагрузка - нарушение нормальной работы системы автоматизации SIMATIC, производимой компанией Siemens, которая обычно используется в различных промышленных системах управления производственными процессами.

Воздействие на систему Siemens SIMATIC

Специалист по информационной безопасности из Германии, Ральф Ленгнер, в сентябре 2010 опубликовал анализ действий Stuxnet относительно SIMATIC на собственном сайте.

SIMATIC WinCC (Windows Control Center) - ПО для создания человеко-машинного интерфейса, составная часть семейства систем автоматизации SIMATIC. Работает под управлением операционных систем семейства Microsoft Windows NT и использует базу данных Microsoft SQL Server 2000 (с версии 6.0). WinCC взаимодействует с пакетом STEP 7.

SIMATIC STEP 7 - ПО для разработки систем автоматизации на основе программируемых логических контроллеров (ПЛК) SIMATIC S7-300/S7-400/M7/C7 и WinAC.

Если Stuxnet определяет, что запущен на инженерной станции, то подменяет часть STEP7, отвечающую за прошивку кода в ПЛК. В момент, когда инженер осуществит подключение к контроллеру, если Stuxnet опознает подходящую конфигурацию аппаратных средств, то модифицирует код, передаваемый в ПЛК. Исследователи выяснили, что злоумышленников интересовали контроллеры 6ES7-417 и 6ES7-315-2, а так же индустриальные сети стандарта Profibus-DP. Модифицированный STEP7, при попытке чтения измененных блоков программы ПЛК отображает их в исходном виде (rootkit компонента для сокрытия факта модификации).

Stuxnet осуществляет идентификацию целевой системы путем проверки блока данных DB 890. Это происходит периодически каждые пять секунд в среде WinCC.

Если условие выполнено, Stuxnet модифицирует модуль ОВ 35 во время передачи из Simatic Manager в ПЛК. Модуль ОВ 35 вызывается в ПЛК каждые 100 мс по таймеру, в нем перехватчик Stuxnet проверяет код возврата функции FC 1874. Если код возврата из FC 1874 - DEADF007, оригинальное содержимое ОВ 35 не выполняется.

Код Stuxnet в ПЛК позволяет:

· слушать сеть Profibus-DP (по которой общаются ПЛК), и генерировать свои пакеты, причем данные для этих пакетов могут обновляться с инженерной станции;

· читать входы ПЛК и управлять его выходами, к ним подключены датчики и исполнительные механизмы (ИМ) соответственно, при этом для целенаправленного воздействия нужно знать конкретно, какие датчики/ИМ подключены к каким входам/выходам;

· синхронизировать свои копии среди зараженных ПЛК по сети Profibus-DP (ПЛК не могут заражаться друг от друга, исполняемый код контроллеров не может переписываться «на лету», только данные, это ограничение контроллеров Siemens).

Так же Stuxnet пытается подключиться к базе данных WinCC, используя «пароль по умолчанию».

Siemens подтверждает, что целью вируса является конкретная технологическая конфигурация. Всего компания сообщила о 15 случаях заражения на производстве, в основном в Германии. Ни в одном случае Stuxnet не внедрился в ПЛК, так как не совпали параметры. При этом на работе оборудования это не сказалось, и во всех случаях Stuxnet удалось нейтрализовать [3].

2.2 Duqu

1 сентября 2011, из Венгрии, на сайт VirusTotal был отправлен файл с именем ~DN1.tmp. На тот момент файл детектировался как вредоносный только двумя антивирусными движками -- BitDefender и AVIRA. Так начиналась история Duqu. Забегая наперед, нужно сказать, что семейство ВПО Duqu было названо так по имени этого файла. Однако этот файл является полностью самостоятельным шпионским модулем с функциями Кей логгера, установленного, вероятно, с помощью вредоносного загрузчика-дроппера, и может рассматриваться только в качестве «полезной нагрузки», загруженной ВПО Duqu в процессе своей работы, но не составной частью (модулем) Duqu. Один из компонентов Duqu был отправлен на сервис Virustotal только 9 сентября. Его отличительная особенность -- это драйвер, подписанный цифровой подписью компании C-Media. Некоторые эксперты тут же принялись проводить аналогии с другим знаменитым образцом ВПО -- Stuxnet, который тоже использовал подписанные драйверы. Общее количество зараженных Duqu компьютеров, обнаруженными различными антивирусными компаниями по всему миру, исчисляется десятками (см. рис. 2.1). Многие компании утверждают, что опять главная цель -- Иран, однако судя по географии распределения заражений, этого нельзя утверждать наверняка.

Рис. 2.1 - Страны, в которых компьютеры подверглись заражению Duqu

В данном случае следует уверенно говорить только об очередной компании с новомодным словом APT (advanced persistent threat).

Расследование, проводимое специалистами Венгерской организации CrySyS (Венгерская лаборатория криптографии и системной безопасности Будапештского университета технологии и экономики), привело к обнаружению установщика (дроппера), посредством которого происходило заражение системы. Он представлял собой файл формата Microsoft Word с эксплоитом уязвимости драйвера win32k.sys (MS11-087, описана Microsoft 13 ноября 2011), отвечающего за механизм рендеринга TTF шрифтов. Шелкод эксплоита использует встроенный (embedded) в документ шрифт с названием 'Dexter Regular', в качестве создателя шрифта указана компания Showtime Inc. Как видно, создателям Duqu не чуждо чувство юмора: Dexter -- серийный убийца, герой телевизионного сериала, снимаемый компанией Showtime. Dexter убивает только (по возможности) преступников, то есть преступает закон во имя законности. Вероятно, таким образом, разработчики Duqu иронизируют, что они занимаются противоправной деятельностью с благими целями. Отправка писем по электронной почте велась целенаправленно. Для отправки, скорее всего, использовались скомпрометированные (взломанные) компьютеры в качестве посредника для затруднения отслеживания.

В документе Word, таким образом, находились следующие компоненты:

· текстовое содержимое;

· встроенный шрифт;

· шелкод эксплоита;

· драйвер;

· инсталлятор (библиотека DLL).

В случае успешного срабатывания шелкод эксплоита выполнял следующие операции (в режиме ядра):

· производилась проверка на повторное заражение, для этого в реестре по адресу 'HKEY_LOCAL_MACHINE\ SOFTWARE\Microsoft\

Windows\CurrentVersion\InternetSettings\Zones\4\' проверялось наличие ключа 'CF1D', если это было верно, шелкод завершал свое выполнение;

· расшифровывались два файла -- драйвер (sys) и инсталлятор (dll);

· драйвер инжектировался в процесс services.exe и выполнял запуск инсталлятора;

· в завершении шелкод затирал себя нулями в памяти.

Благодаря тому, что win32k.sys выполняется от имени привилегированного пользователя 'System', разработчиками Duqu была элегантно решена задача, как несанкционированного запуска, так и повышения прав (запуск из-под аккаунта пользователя с ограниченными правами).

Инсталлятор после получения управления расшифровывал в памяти, находящиеся в нем три блока данных, содержащих:

· подписанный драйвер (sys);

· основной модуль (dll);

· данные конфигурации инсталлятора (pnf).

В данных конфигурации инсталлятора был задан диапазон дат (в виде двух временных меток -- начальной и конечной). Инсталлятор проверял, попадает ли текущая дата в него, если нет -- завершал свое выполнение. Также в данных конфигурации инсталлятора были указаны имена, под которыми сохранялись драйвер и основной модуль (см. рис. 2.2). При этом основной модуль сохранялся на диске в зашифрованном виде.

Для автозапуска Duqu создавалась служба, использующая файл драйвера, который расшифровывал основной модуль на лету, при помощи ключей, сохраненных в реестре. Основной модуль содержит в себе свой собственный блок данных конфигурации. При первом запуске он расшифровывался, в него заносилась дата установки, после чего он снова зашифровывался и сохранялся основным модулем. Таким образом, в пораженной системе при успешной инсталляции сохранялись три файла -- драйвер, основной модуль и его файл данных конфигурации, при этом последние два файла хранились на диске в зашифрованном виде. Все процедуры расшифровки проводились только в памяти. Такая сложная процедура установки применялась для минимизации возможности детектирования антивирусным программным обеспечением.

Рис. 2.2 - Внедрение Duqu в систему

Основной модуль (ресурс 302), по информации компании «Лаборатория Касперского», написан с использованием MSVC 2008 на чистом С, однако с использованием объектно-ориентированного подхода. Этот подход является нехарактерным при разработке вредоносного кода. Как правило, такой код пишется на C, чтобы уменьшить размер и избавиться от неявных вызовов, присущих C++. Здесь же наблюдается некий симбиоз. Плюс использовалась событийно-ориентированная архитектура. Сотрудники «Лаборатории Касперского» склоняются к теории, что основной модуль был написан с использованием предпроцессорной надстройки, позволяющей писать код на C в объектном стиле.

Основной модуль отвечает за процедуру получения команд от операторов. В Duqu предусмотрено несколько способов взаимодействия: с использованием протоколов HTTP и HTTPS, а также с помощью именованных каналов (pipe). Для HTTP(S) указываются доменные имена командных центров, при этом предусматривалась возможность работы через прокси-сервер -- для них задавались имя пользователя и пароль. Для канала задаются IP адрес и его имя. Указанные данные хранятся в блоке данных конфигурации основного модуля (в зашифрованном виде).

Для использования именованных каналов запускалась собственная реализация RPC сервера. Она поддерживала выполнение следующих семи функций:

· вернуть установленную версию;

· выполнить инжект dll в указанный процесс и вызвать указанную функцию;

· загрузить dll;

· запустить на выполнение процесс посредством вызова CreateProcess();

· читать содержимое заданного файла;

· записать данные в заданный файл;

· удалить заданный файл.

Именованные каналы могли использоваться внутри локальной сети для распространения между зараженными Duqu компьютерами обновленных модулей и данных конфигурации. Кроме того, Duqu мог выступать в качестве прокси-сервера для других зараженных компьютеров (у которых не было доступа к Интернету из-за настроек сетевого экрана на шлюзе). В отдельных версиях Duqu функционал RPC отсутствовал.

Компанией Symantec было обнаружено, по меньшей мере, четыре вида «полезной нагрузки», загруженной по команде от управляющего центра Duqu.

При этом только одна из них была резидентной и скомпилированной в виде исполняемого файла (exe), который сохранялся на диск. Остальные три были выполнены в виде dll библиотеки. Они загружались динамически и выполнялись в памяти без сохранения на диск.

Резидентная «полезная нагрузка» представляла собой шпионский модуль (infostealer) с функциями кейлоггера. Именно с отправки его на VirusTotal и началась работа по исследованию Duqu. Основной шпионский функционал находился в ресурсе, первые 8 килобайт которого содержали часть фото галактики NGC 6745 (для маскировки). Здесь нужно напомнить, что в апреле 2012 года в некоторых СМИ публиковалась информация (http://www.mehrnews.com/en/newsdetail.aspx?NewsID=1297506), что Иран подвергся воздействию некого вредоносного программного обеспечения «Stars», при этом подробности инцидента не раскрывались. Возможно, именно такой образец «полезной нагрузки» Duqu был обнаружен тогда в Иране, отсюда и название -- «Stars» (звезды).

Шпионский модуль собирал следующую информацию:

· список запущенных процессов, информацию о текущем пользователе и домене;

· перечень логических дисков, включая сетевые;

· снимки экрана;

· адреса сетевых интерфейсов, таблицы маршрутизации;

· лог-файл нажатий клавиш клавиатуры;

· имена открытых окон приложений;

· перечень доступных ресурсов сети (sharing resources);

· полный список файлов на всех дисках, включая съемные;

· список компьютеров в «сетевом окружении».

Еще один шпионский модуль (infostealer) представлял собой вариацию уже описанного, но скомпилированного в виде dll библиотеки, из него были убраны функции кейлоггера, составления списка файлов и перечисления компьютеров, входящих в домен.

Следующий модуль (reconnaissance) собирал системную информацию:

· является ли компьютер часть домена;

· пути к системным каталогам Windows;

· версию операционной системы;

· имя текущего пользователя;

· список сетевых адаптеров;

· системное и местное время, а также часовой пояс.

Последний модуль (lifespan extender) реализовывал функцию увеличения значения (храниться в файле данных конфигурации основного модуля) количества дней, оставшихся до завершения работы. По умолчанию это значение устанавливалось равным 30 или 36 дням в зависимости от модификации Duqu, и уменьшалось на единицу каждый день.

20 октября 2011 года (спустя три дня после распространения информации об обнаружении) операторы Duqu провели процедуру уничтожения следов функционирования командных центров. Командные центры размещались на взломанных серверах по всему миру -- во Вьетнаме, Индии, Германии, Сингапуре, Швейцарии, Великобритании, Голландии, Южной Корее. Интересно, что все выявленные сервера работали под управлением ОС CentOS версий 5.2, 5.4 или 5.5. ОС были как 32-битными, так и 64-битными. Несмотря на то, что все файлы, касающиеся работы командных центров, были удалены, специалистам «Лаборатории Касперского» удалось восстановить часть информации LOG файлов из slack space. Наиболее интересный факт, что злоумышленники на серверах всегда заменяли пакет OpenSSH 4.3, установленный по умолчанию, на версию 5.8. Это может указывать на использование для взлома серверов неизвестной уязвимости в OpenSSH 4.3. Не все системы использовались в качестве командных центров. Некоторые, судя по ошибкам в логах sshd при попытках перенаправления трафика для портов 80 и 443, использовались в качестве прокси-сервера для соединения с конечными командными центрами [4].

2.3 Flame

Вирусы Duqu и Stuxnet повысили градус кибервойны на Ближнем Востоке, однако недавно обнаружили, пожалуй, самое изощренное кибероружие на сегодняшний день. Червь Flame, созданный для кибершпионажа, попал в поле зрения экспертов «Лаборатории Касперского» при проведении исследования по запросу Международного союза электросвязи (МСЭ), обратившегося за содействием в поиске неизвестной вредоносной программы, которая удаляла конфиденциальные данные с компьютеров, расположенных в странах Ближнего Востока. В процессе поиска этой программы, получившей название Wiper, ЛК обнаружили новый образец вредоносного ПО, который был назван Worm.Win32.Flame.

Хотя Flame имеет иной функционал, чем печально известные образцы кибероружия Duqu и Stuxnet, все эти вредоносные программы имеют много общего: географию атак, узкую целевую направленность в сочетании с использованием специфических уязвимостей в ПО. Это ставит Flame в один ряд с «кибернетическим супероружием», развертываемым на Ближнем Востоке неизвестными злоумышленниками. Без сомнения, Flame является одной из самых сложных киберугроз за всю историю их существования. Программа имеет большой размер и невероятно сложную структуру. Она заставляет переосмыслить такие понятия, как «кибервойна» и «кибершпионаж».

Flame представляет собой весьма хитрый набор инструментов для проведения атак, значительно превосходящий по сложности Duqu. Это троянская программа -- бэкдор, имеющая также черты, свойственные червям и позволяющие ей распространяться по локальной сети и через съемные носители при получении соответствующего приказа от ее хозяина.

Исходная точка входа Flame неизвестна -- подозревают, что первоначальное заражение происходит путем целевых атак, однако найти исходный вектор атаки так пока не удалось. Подозревают, что используется уязвимость MS10-033, однако в данный момент подтвердить это не могут.

После заражения системы Flame приступает к выполнению сложного набора операций, в том числе к анализу сетевого трафика, созданию снимков экрана, аудиозаписи разговоров, перехвату клавиатурных нажатий и т.д. Все эти данные доступны операторам через командные серверы Flame.

В дальнейшем операторы могут принять решение о загрузке на зараженные компьютеры дополнительных модулей, расширяющих функционал Flame. Всего имеется около 20 модулей, назначение большинства которых в данный момент изучают.

Прежде всего, Flame -- это огромный пакет, состоящий из программных модулей, общий размер которых при полном развертывании составляет почти 20 МБ. Вследствие этого анализ данной вредоносной программы представляет огромную сложность. Причина столь большого размера Flame в том, что в него входит множество разных библиотек, в том числе для сжатия кода (zlib, libbz2, ppmd) и манипуляции базами данных (sqlite3), а также виртуальная машина Lua.

Lua -- это скриптовый язык, т.е. язык программирования, легко поддающийся расширению и интеграции с кодом, написанным на языке C. Для многих компонентов Flame логика верхнего уровня написана на Lua -- при этом подпрограммы и библиотеки, непосредственно реализующие заражение, компилируются с C++.

По сравнению с общим объемом кода часть, написанная на Lua, относительно невелика. По оценке «Лаборатории Касперского», объем разработки на Lua составляет более 3000 строк кода. Для среднего разработчика на создание и отладку такого объема кода требуется около месяца.

Рис. 2.3 - Декомпилированный код Flame на языке Lua

Кроме того, вредоносная программа использует для внутренних нужд локальные базы данных с вложенными SQL-запросами, применяет несколько методов шифрования, различные алгоритмы сжатия, создает скрипты с помощью Windows Management Instrumentation, использует пакетные скрипты и т.д.

Запуск и отладка вредоносного ПО -- нетривиальная задача, поскольку вредоносная программа представляет собой не обычный исполняемый файл, а несколько DLL-библиотек, загружаемых при запуске операционной системы.

В целом можно констатировать, что Flame -- одна из наиболее сложных угроз, обнаруженных на сегодняшний день.

Flame отличается от других троянцев-бэкдоров тем, что для вредоносного ПО нехарактерно использование Lua. Достаточно большой размер набора инструментов для проведения атак также нетипичен для вредоносного ПО. Как правило, современные вредоносные программы имеют небольшой размер и пишутся на языках программирования, обеспечивающих максимальную компактность, что помогает скрыть присутствие этих программ в системе. Сокрытие с помощью большого объема кода -- это новая черта, реализованная в Flame.

Запись аудиоданных со встроенного микрофона -- тоже достаточно новый прием. Конечно, существуют и другие вредоносные программы, способные записывать аудио, однако ключ в универсальности Flame -- способности этой вредоносной программы красть данные столь разнообразными способами.

Еще одна любопытная функция Flame -- использование Bluetooth в устройствах, поддерживающих такой способ передачи данных. Если Bluetooth поддерживается зараженным компьютером и включен в настройках, программа собирает информацию об обнаруживаемых устройствах, находящихся вблизи зараженной машины. Если в конфигурации включены соответствующие настройки, Flame может превратить зараженную машину в радиомаяк, настроив разрешение на его обнаружения другими Bluetooth-устройствами и сообщая общие данные о состоянии заражения, зашифрованные в передаваемой по Bluetooth информации об устройстве.

Несмотря на то что еще не до конца проанализировали различные модули Flame, уже сейчас можно утверждать, что программа способна записывать аудиосигнал через микрофон, если таковой имеется. Записанный звук хранится в сжатом формате, причем сжатие обеспечивается с помощью общедоступной библиотеки.

Записанные аудиоданные регулярно, по расписанию, скрытым образом пересылаются на командный сервер через SSL-канал.

Вредоносная программа способна регулярно делать снимки экрана; более того, она делает скриншоты в процессе работы определенных «интересных» приложений, таких как системы мгновенного обмена сообщениями. Снимки экрана хранятся в сжатом формате и регулярно пересылаются на командный сервер -- так же, как и аудиозаписи.

Авторы Flame специально изменили даты создания файлов таким образом, чтобы исследователи не смогли узнать, когда зловред был создан на самом деле. Файлы датированы годами 1992, 1994, 1995 и т. д. -- очевидно, что эти даты не имеют отношения к действительности.

Полагают, что проект Flame в основной части был создан не раньше 2010 года и до настоящего времени находится в активной разработке. Его авторы постоянно вносят изменения в разные модули, продолжая при этом использовать ту же архитектуру и имена файлов. Многие модули изменялись или создавались в 2011-2012 годах.

По данным, Flame использовался в августе 2010 г. При этом, исходя из косвенных данных можно сказать с уверенностью, что уже в феврале-марте 2010 г. Flame был активен «в дикой среде». Высока вероятность, что существовал и более ранний вариант, хотя подтверждений нет.

Что стоит за названием Flame?

Flame -- это большой набор инструментов, состоящий из нескольких модулей. Один из главных модулей был назван Flame -- это модуль, отвечающий за проведение атак и заражение новых компьютеров (см. рис. 2.4).

Рис. 2.4 - Модуль установки Flame

Так кто же стоит за разработкой такого зловреда? В настоящее время известно три вида игроков, разрабатывающих вредоносные программы и шпионское ПО: хактивисты, киберпреступники и государства. Flame не предназначен для кражи денег с банковских счетов. Он также явным образом отличается от довольно простых инструментов хакеров и зловредов, используемых хактивистами. Таким образом, после исключения киберпреступников и хактивистов, в списке остаётся только одна группа.

Наконец, если принять во внимание географию жертв (конкретные страны на Ближнем Востоке) и уровень сложности угрозы, не остаётся сомнений, что за ней стоит некое государство, которое и спонсировало его разработку.

В коде зловреда нет информации, которая указывала бы на конкретное государство. Анализ прочей доступной информации также не позволяет связать Flame с какой-либо конкретной страной. Таким образом, авторство остаётся неустановленным, как это было и в случае Stuxnet и Duqu.

Для систематического сбора информации о действиях конкретных стран на Ближнем Востоке, включая Иран, Ливан, Сирию, Израиль и др(см. рис. 2.5).

Вот семь стран, подвергшихся наибольшему количеству атак:

Рис. 2.5 - Страны, подвергшиеся атакам

Первоначальный анализ указывает на то, что создатели Flame стремятся получить любые данные: электронные письма, документы, сообщения, разговоры на территории секретных объектов -- практически всё. До сих пор не было каких-либо указаний на конкретную цель Flame, скажем на энергетическую отрасль. Это позволяет считать, что Flame является универсальным набором инструментов для проведения атак, разработанным для кибершпионажа в широком смысле.

Как уже видели ранее, такие универсальные зловреды могут использоваться для загрузки модулей, предназначенных для атаки на специфические объекты, такие как, автоматизированные системы управления, критически важные объекты инфраструктуры и т.д.

Так как Flame имеет большой размер, вредоносную программу так долго не могли обнаружить. Современные вредоносные программы в основном небольшие и имеют определенные цели. Легче спрятать небольшой файл, чем большой модуль. Кроме того, загрузка 100K через ненадежную сеть имеет гораздо больше шансов на успех, чем загрузка 6MB.

Модули Flame вместе составляют более 20 МБ. Многие из них являются библиотеками, предназначенными для обработки SSL-трафика, SSH-соединений, контроля сообщений, передаваемых по сети связи, с целью выявления конфиденциальной информации, проведения атак, перехвата сообщений и т.п. Возьмем такой пример: ЛК потребовалось несколько месяцев, чтобы проанализировать 500-килобайтовый код Stuxnet. А на то, чтобы полностью понять 20MБ код Flame, вероятно, потребуются годы.

В Flame имеется много различных встроенных таймеров. Они отслеживают успешные соединения с C&C, частоту отдельных операций по краже данных, количество удачных атак и т.д. И хотя в этой вредоносной программе нет таймера самоуничтожения, контролирующие устройства могут послать специальный модуль удаления вредоносной программы (он называется “browse32”), который полностью удаляет программу из системы, стирая все следы ее присутствия там [5].

автоматизированный вирус преобразователь интерфейс

3. Производители SCADA систем

SCADA системы сейчас, являются неотъемлемой частью современных автоматизированных систем управления процессами или как ее еще называют средой визуализации. Получив широкое распространение в начале 20-го века, сегодня уже трудно себе представить объект автоматизации, на который бы не была установлена SCADA система. Уже практически ушли в историю огромные шкафы с панелями вторичных приборов, на смену им пришли автоматизированные рабочие места (АРМ). Внедрение SCADA систем приводит к существенному удешевлению эксплуатации вторичного оборудования на крупных объектах, путем переноса индикации и накопления технологической информации на пульт диспетчера АРМ.

Не смотря на большое разнообразие SCADA систем на рынке, большинство из них имеет примерно одинаковый набор функциональных возможностей, позволяющих выполнять основные требования, предъявляемые к верхнему уровню АСУ ТП. Набор стандартных функций в SCADA системах обусловлен общим кругом задач при разработке систем автоматизации. Определим состав основных функций, позволяющих выполнить полноценный проект по автоматизации:

1. То без чего не обходится ни одна SCADA система - это графический интерфейс, который позволяет упростить задачу построения и отображения технологического процесса (ТП). К графической части можно отнести возможность упрощенного или детализированного отображения объектов ТП, средств измерения физических параметров технологических объектов (ТО). Кроме того, позволяет отображать кнопки, индикаторы, панели стрелочных или цифровых индикаторов, регуляторов и других вторичных приборов, которые раньше располагались на панели шкафа автоматизации. Поддержка библиотек изображений и видео, позволяющая выводить графическую информацию сторонних разработчиков на графическую панель SCADA системы, такие как элементы мнемосхем, динамические объекты.

2. SCADA системы позволяют вести архив измерений, событий и аварийных ситуаций, происходящих на ТО, с отображением изменений информации в окне временного тренда.

3. Упрощенный язык составления алгоритмов управления ТП, математических вычислений.

4. Драйвера устройств и оборудования согласованной работы со SCADA системой, находящихся на нижнем и среднем уровнях АСУ ТП, такие как датчики, вторичное оборудование контроллеры.

5. Поддержка других языков программирования высокого уровня (Visual C++, VBA, VB).

6. И одна из важнейших функций SCADA систем - средства защиты от несанкционированного доступа к файлам и компонентам.

3.1 Master SCADA

Это система визуализации АСУТП, MES, задач учета и диспетчеризации объектов промышленности, ЖКХ и зданий. Для оценки возможностей SCADA системы существует ознакомительная бесплатная версия на 32 точки и учебник по созданию АСУ ТП.

Из других функций Master SCADA доступны следующие возможности:

1. взаимодействие с другими программами с помощью современных технологий (OPC, OLE, DCOM, ActiveX, OLE DB, ODBC и др.)

2. функция использования в операторской панели АСУ ТП документов любого типа и поддержка обмена данными с ними

3. Master SACADA имеет неограниченное расширение функциональности за счет использования продуктов сторонних разработчиков

4. наличие открытого интерфейса для создания пользователем любых базовых элементов

5. Единая среда разработки всего проекта

6. Раздельное конфигурирование структуры системы и логической структуры объекта

7. Открытость и следование стандартам

8. Интуитивная легкость освоения

9. Мощная трехмерная графика и мультимедиа

10. Неограниченная гибкость вычислительных возможностей

11. Объектный подход

12. Бесплатная инструментальная SCADA-система

13. Бесплатная исполнительная система на 32 точки

14. Галерея мнемосхем с объектов

15. Мaster SCADA в картинках

16. Видео примеры разработки проектов

17. Тысячи внедренных систем

18. ответы на часто задаваемые вопросы по ценам на Master SCADA

3.2 SCADA TRACE MODE

TRACE MODE® - это первая интегрированная информационная система для управления промышленным производством, объединяющая в единые целые продукты класса SOFTLOGIC-SCADA / HMI-MES-EAM-HRM. SCADA система TRACE MODE разработана в 1992 году и к настоящему времени имеет более 7000 внедрений на объектах АСУ ТП. На данный момент актуальной версией является SCADA система TRACE MODE® 6.

...