Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 9586 сообщений
Cообщения с меткой

информационная безопасность - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

Навыки и требования к специалистам по информационной безопасности

Вторник, 26 Июля 2016 г. 13:37 (ссылка)





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



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





Cтатистика



По статистике одного из HR-агенств, специалистам по информационной безопасности в конце 2015 г. предлагали в среднем на 21% больше, чем в январе 2015 г. Это указывает на то, что даже в условиях кризиса квалифицированные специалисты востребованы, более того, рынок ощущает их нехватку.



Действительно, тема информационной безопасности стала как никогда актуальной — это и набирающие обороты (по уровню ущерба и частоте) атаки банковского сектора (SWIFT, корреспондентские счета), увеличивающееся количество таргетированных атак (Advanced Persistent Threat, APT) и т.д.



Даже те компании, штат которых укомплектован специалистами по информационной безопасности, нуждаются в квалифицированной оценке зрелости защитных систем, безопасности периметра, веб-приложений и иных элементов инфраструктуры — показательно всё увеличивающееся количество инициаторов BugBounty программ, причём сумма выплат колеблется от $100 до $20000 за уязвимость.



Вакансии



Исходя из данных, представленных на сайтах по размещению вакансий средний уровень заработной платы специалистов по информационной безопасности с опытом 1-3 года находится на уровне 40.000-70.000 рублей. Это относится к специалистам начальной группы (junior), с малым опытом работы, по профессиональным требованиям и обязанностям это хорошо видно (здесь и далее представлены «усреднённые» показатели):



Обязанности:


  • Администрирование межсетевых экранов Cisco ASA и Kerio Connect;

  • Администрирования сервера антивирусной защиты, мониторинг состояния клиентов, удаление вирусов, тонкая настройка защиты;

  • Поиск уязвимостей с помощью специализированного ПО и их устранение;

  • Мониторинг выхода обновлений для ОС, ПО и сетевого оборудования;

  • Настройка и управление коммутационным оборудованием;

  • Написание скриптов оптимизации управления системами безопасности;

  • Управление инфраструктурой предоставления доступов;

  • Периодический анализ логов.



Требования:


  • Опыт администрирования ОС Windows от 1-го года;

  • Базовые знания ОС Linux от 1-го года, уверенная работа в командной строке;

  • Базовые знания работы сетей. IP адресация, статическая маршрутизация, модели ISO OSI, TCP;

  • Опыт администрирования Active Directory: настройка групповых политик(GPO), управление правами пользователями;

  • Опыт настройки систем защиты от НСД на базе Windows;

  • Опыт настройки антивирусных систем;

  • Опыт разработки сложных конфигураций межсетевого экрана IPTables;

  • Умение настраивать Apache2, nginx, Auditd, MySQL, PostgreSQL, Rsyslog.



Как видно из описания это скорее системный администратор с уклоном в ИБ, нежели «чистый» безопасник. Какую-то определенную конкретику в навыках выделить сложно. Кто ищет кандидатов — компании любой направленности, выделить область сложно.




Специалисты с опытом 3-6 лет относятся уже к middle. Навыков и опыта требуется больше, но и уровень заработной платы гораздо выше. Эти специалисты, как правило, имеют хороший технический бэкграунд (системное администрирование, поиск узявимостей), хорошо знают приложения, техники и методологию. Этих специалистов условно можно разделить на два направления — нападение и защита. Универсалов на этом уровне (пентестер + специалист по обеспечению ИБ) — практически не бывает в природе (либо это уже уровень senior). Средняя вилка — 70.000-100.000 рублей.



Специалист по защите информации:



Обязанности:


  • Настройка и управление подсистемами безопасности;

  • Управление инцидентами безопасности;

  • Настройка и управление коммутационным оборудованием;

  • Написание скриптов оптимизации управления системами безопасности;

  • Управление инфраструктурой предоставления доступов;

  • Анализ логов-файлов и журналов событий;

  • Участие в сопровождении IT-инфраструктуры Заказчика: обеспечение информационной безопасности и защиты персональных данных;

  • Мониторинг и контроль функционирования средств обеспечения ИБ;

  • Поддержка работоспособности, администрирование и обеспечение бесперебойной работы специальных средств защиты информации;

  • Внесение изменений в настройки средств обеспечения безопасного межсетевого взаимодействия при обнаружении признаков атаки на ВС;

  • Контроль нештатной активности внутренних пользователей ВС;

  • Анализ инцидентов ИБ и их решение;

  • Проведение аудитов, подготовка организационно-распорядительной документации и отчетов по ИБ.



Требования:


  • Высшее образование (ИТ, информационная безопасность);

  • Знание принципов построения и функционирования сетей и протоколов стека TCP/IP;

  • Знание модели ISO/OSI;

  • Понимание принципов компьютерной и сетевой безопасности, безопасности web- приложений;

  • Знание принципов работы средств обеспечения безопасности (корпоративные антивирусы,WAF, системы обнаружения вторжений и т.д.);

  • Windows и Linux на уровне администратора;

  • Опыт автоматизации (bash, perl, python);

  • Опыт проведения анализа защищенности;

  • Профессиональные знания используемого в инфраструктуре работодателя профильного ПО (от корпоративных антивирусов до DLP/IDS/IPS/SIEM и т.д).



Пентестер:



Обязанности:


  • Выполнение тестирования информационных сред и программных продуктов компании;

  • Тестирование информационных систем на отказоустойчивость;

  • Инструментальный анализ информационных систем;

  • Выявление актуальных угроз по классификации OWASP TOP 10, выработка компенсирующих мер;

  • Тестирование на проникновение;

  • Анализ безопасности исходных кодов программных продуктов.



Требования


  • Опыт работы по выявлению уязвимостей систем;

  • Опыт работы с Burp Suite, Hydra;

  • Опыт работы SQLMap, OpenVAS, Metasploit Framework, Fortify, AppScan;

  • Опыт работы Acunetix, w3af, X-Spider, Max-Patrol, Nmap;

  • Знание принципов построения и работы веб-приложений;

  • Знание типовых угроз и уязвимостей веб-приложений, перечисленных в OWASP Top 10;

  • Навыки ручного и автоматизированного тестирования безопасности веб-приложений;

  • Опыт проведения тестирования на проникновение;

  • Опыт проведения аудита систем ИТ и ИБ.



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




Cпециалисты с опытом работы от 5-6 лет — senior. Как правило это руководящая должность — начальник отдела анализа защищенности; начальник отдела управления информационной безопасности; аналитик; крупный сейл ИБ-вендора; узскопециализированный пентестер. Уровень заработной платы от 120.000 до 200.000 рублей.



Людей из этой категории довольно мало, и, как правило, они «на слуху» в отрасли. Это специалисты, хорошо разбирающиеся в предметной области, и, как правило, имеющие экспертную квалификацию в узкой специализации. Приветствуется опыт выступления на конференциях либо другая общественная активность — значит кандидат следит за трендами и получает своевременную оценку профессионального сообщества.



Из требований здесь встречаются следующие:


  • Высшее ИБ/ИТ образование;

  • Наличие сертификатов;

  • Наличие публикаций и статей в предметной области;

  • Опыт публичных выступлений;

  • Знание основных методик, классификаций и международных практик (OSSTMM, OWASP, WASC, NIST SP800-115 и др.);

  • Навыки выявления угроз ИБ на основе сведений об уязвимостях (классификация угроз, формирование рекомендаций по устранению уязвимостей и минимизации бизнес-рисков);

  • Знание нормативной базы в части защиты информации: законов и иных нормативных правовых актов РФ, регулирующих отношения, связанные с защитой информации ограниченного доступа (не относящейся к гостайне), руководящих документов ФСТЭК, ФСБ, в том числе по защите банковской тайны, АСУ ТП, коммерческой тайны, знание СТО БР ИББС, PCI DSS, ISO 27xxx;

  • Английский язык;

  • Наличие лидерских качеств, умение добиваться поставленных целей, инициативность, активность, навыки самоорганизации, ответственность;

  • Умение программировать на одном или нескольких скриптовых языках;

  • Экспертные знания профильного ПО (IBM Qradar, Splunk Enterprise, Imperva DAM, Maxpatrol, Symantec Critical System Protection, Tuffin, Gigamon Networks и Cisco ASA. и т.д);

  • Экспертные знания в узкоспециализированных системах: (например SCADA/ERP/SS7/Hardware);

  • Опыт разработки собственных средств/утилит/методик;

  • Опыт разработки технической и аналитической документации;

  • Опыт проведения статистических исследований;

  • Опыт расследования инцидентов безопасности, сбор доказательной базы, форензика;

  • Опыт участия в крупных проектах по анализу защищенности или аудиту информационной безопасности.



Требования представлены в усредненном варианте для вышеперечисленных специалистов. Профессиональные навыки соискателя, как правило, известны и таких людей «хантят» не под определенную задачу, а под целый этап или уровень жизнедеятельности компании. Такого рода специалисты востребованы в финансовой сфере, ИТ-интеграторах, ИБ-вендорах, крупных ИТ-компаниях.




Вершина пирамиды (lead) — специалисты с опытом от 10 лет. К этой категории относятся CTO, CISO, системный архитектор, team lead. Уровень зарплаты от 200.000. Как правило, это известные люди в отрасли информационной безопасности, с обширным опытом и связями.



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



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



Подводя итоги



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



Проблема образования и дальнейшего трудоустройства заключается в извечной проблеме «нет работы, потому что нет опыта, потому, что нет работы…» и читать эту фразу можно по кругу бесконечно. Общепризнанный факт, что диплом сам по себе не дает приоритета. К моменту выпуска бОльшая часть знаний уже не котируется.

Наиболее быстрый и удачный выход из ситуации – самообразование. Изучение последних тенденций посредством специализированных курсов, который проводят специалисты с более чем 10-летним стажем работы в области практической ИБ. На курсах «Корпоративные лаборатории» мы поможем получить и применить нехватающие знания, и как следствие повысить уровень Ваших навыков и востребованность на рынке труда.



Всех заинтересованных в повышении своего профессионального уровня мы приглашаем ознакомиться с программой обучения.



Оставаться годами junior или стремиться и дорасти до lead – личный выбор каждого.
Original source: habrahabr.ru.

https://habrahabr.ru/post/306336/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Использование custom functions в парсерах OSSIM

Воскресенье, 24 Июля 2016 г. 11:15 (ссылка)

Доброго дня, уважаемые!

В продолжение моей статьи хочу рассмотреть и поделиться опытом работы с функционалом «custom functions», используемом в OSSIM. Это функции, которые предназначены для обработки полученной вследствие разбора (парсинга) журналов событий информации. Обработка может заключаться в разрешении имени по IP адресу, определении геолокации и всего того, на что хватит фантазии. В примере ниже я разберу вариант использования «custom functions» для дополнительного парсинга полученной информации.



1. Для чего это нужно?



Предположим, что вы извлекаете журналы событий из базы данных (далее — БД), как я описывал в статье. И случилось так, что в одном из полей БД у Вас лежит не одно какое-то значение, например «имя пользователя» или «IP адрес», а целая строка сообщения из которой нужно выделить ключевые слова (например, строка вида «issued command: ls /root; result: ACCEPT»). И Вам из данной строки нужно получить текст команды (ls /root) и результат ее выполнения (ACCEPT).

Очевидно, что стандартным функционалом, доступным для источников журналов событий типа «mysql», это сделать невозможно. Тут-то и приходит на помощь функционал «custom functions». С его помощью из полученной строки мы сможем выделить интересующие нас фрагменты информации. Итак, приступим.



2. Формулировка задачи



На базе примера из статьи необходимо выделить информацию об отданной команде (все, что следует после «command:») и результате ее выполнения (все, что следует после «result:») из строки лога, хранимой в базе данных в поле «message». Записать текст команды в поле «userdata3», а результат выполнения команды в поле «userdata4».

Пример таблицы из БД:

+---------------------+----------+----------------------+----------+--------------------------------------------+
| date | event_id | event_type | username | message |
+---------------------+----------+----------------------+----------+--------------------------------------------+
| 2016-07-22 17:17:05 | 283 | type 1 | net_adm | issued command: show arp; result: ACCEPT |
| 2016-07-22 17:17:49 | 284 | suspicious activity | operator | issued command: show arp; result: ACCEPT |
| 2016-07-22 17:17:50 | 285 | suspicious activity | admin | issued command: show arp; result: ACCEPT |
| 2016-07-22 17:17:51 | 286 | suspicious activity | guest | issued command: show arp; result: ACCEPT |
| 2016-07-22 17:17:52 | 287 | type 1 | unknown | issued command: show arp; result: ACCEPT |
| 2016-07-22 17:17:53 | 288 | type 1 | valeriy | issued command: show arp; result: ACCEPT |
| 2016-07-22 17:17:54 | 289 | suspicious activity | alex | issued command: show arp; result: ACCEPT |
| 2016-07-22 17:17:55 | 290 | type 1 | cisco | issued command: show arp; result: ACCEPT |
| 2016-07-22 17:17:57 | 291 | suspicious activity | net_adm | issued command: show arp; result: ACCEPT |
+---------------------+----------+----------------------+----------+--------------------------------------------+


3. Решение



Для решения задачи будет выполнено:


  • создание функции для выделения информации о команде;

  • создание функции для выделения информации о результате выполнения команды;

  • дополнительная настройка парсера (ранее созданного в примере).



3.1. Создание функции для выделения информации о команде


Для того, чтобы использовать свою собственную функцию в парсере OSSIM необходимо добавить ее в файл:

/usr/share/alienvault/ossim-agent/ParserUtil.py


Функции пишутся на python. Добавлять их в файл можно в любое место. Я дописал после «dummy function».

Я написал следующую функцию для выделения информации об отданной команде из текста события:

def parse_command(input):
res = re.search(r'command:.*;', input)
return (res.group(0).split(": ")[1].strip(";"))


Как видно, данная функция с помощью регулярного выражения получает необходимую информацию (все, что находится после «command:» и до последней ";". Говорю последняя т.к. в теле команды тоже могут присутствовать ";") и возвращает ее агенту OSSIM для дальнейшей обработки парсером.



3.2. Создание функции для выделения информации о результате выполнения команды


Аналогично пишем вторую функцию и добавляем ее в файл:

def parse_result(input):
res = re.search(r'result:\s+\S+', input)
return (res.group(0).split(": ")[1])


3.3. Дополнительная настройка парсера


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

Для использования созданных функций в парсере OSSIM используется конфигурационная строка вида:

<поле OSSIM>={<имя функции>(<параметр>)}

Этой строкой мы сообщаем агенту OSSIM в какое поле схемы описания события OSSIM нужно поместить информацию, получаемую применением функции к параметру. А параметром в нашем случае является информация, полученная из БД из поля «message», т.е. текст события вида «issued command: show arp; result: ACCEPT».

Поля OSSIM в нашем примере будут: userdata3, userdata4

Функции, соответственно: «def parse_command» и «def parse_result»

Параметром будет "$4"

В итоге, строки, которые нужно ддобавить в конфигурационный файл парсера выглядят так:

userdata3={parse_command($4)}
userdata4={parse_result($4)}


Ниже приведен итоговый фрагмент (секция query) конфигурационного файла парсера OSSIM:

[query]
query="select event_id, date, event_type, username, message from data_table where event_id > $1;"
#order by event_id desc limit 1
regexp=
ref=0
date={normalize_date($1)}
plugin_sid={translate($2)}
username={$3}
userdata1={$4}
userdata2={$2}
userdata3={parse_command($4)}
userdata4={parse_result($4)}


После выполнения данных манипуляций необходимо перезапустить агента OSSIM:

/etc/init.d/ossim-agent restart


После перезапуска не лишним будет проследить за сообщениями в файле лога на предмет ошибок (вдруг где-то закралась):

tail -f /var/log/alienvault/agent/agent.log|grep ERROR


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



Рисунок 1 – Разобранные события в интерфейсе OSSIM



77. Усовершенствование



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

Например, передавая (текст, 1) получать команду, а (текст, 2) — соответственно, результат. Такое решение мне кажется наиболее изящным.

Я даже написал под это функцию, которая отрабатывает, если запускать ее в командной строке сервера. Но вот агент OSSIM никак не желает принимать два параметра, только один.

Я обратился в alienvault с этим вопросом, но пока ответа не получил. Если у кого есть размышления на эту тему, прошу, пишите в личку или комментарии.

Заранее спасибо!
Original source: habrahabr.ru.

https://habrahabr.ru/post/306258/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Security Week 29: утечка на форуме Ubuntu, прокси-уязвимость в PHP, Go и Python, 276 заплаток Oracle

Пятница, 22 Июля 2016 г. 12:08 (ссылка)

14 июля в Canonical узнали, что кто-то владеет (возможно и пытается продать) базой логинов и паролей двух миллионов пользователей форумов Ubuntu. Расследование быстро показало, что информация похожа на правду, после чего форумы были просто временно отключены. Надо сказать, это очень правильный ход, хотя в другой компании и в другой ситуации на него могли бы и не решиться: как же так, ведь все узнают, что у нас проблемы с безопасностью, а так может никого и не взломают. Собственно, мы все это знаем благодаря подробному описанию инцидента на сайте разработчиков Ubuntu, так что вроде бы все закончилось хорошо.



Или нет? Утечка (подробное описание событий в этой новости) началась со эксплуатации уязвимости в плагине Forumrunner, установленного на vBulletin, при помощи SQL-инъекции. Атака стала возможной из-за использования устаревшей версии плагина. Инъекция открыла доступ на чтение ко всей базе данных форума, но, как утверждает Джейн Сильбер, директор Canonical, взломщику удалось скачать только часть пользовательской базы с «устаревшими» паролями, которые к тому же были захешированы с солью.



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



HTTPoxy: уязвимость в реализации интерфейса CGI затрагивает большое количество сетевого софта

Новость.



У нас еще одна уязвимость с привлекательным брендом и даже логотипом, но кажется мы к такому уже привыкли. Тем более, что уязвимость заслуживает внимания широченным охватом подверженного софта. Как правило такие универсальные дыры обнаруживаются в многократно используемых библиотеках: можно вспомнить прошлогодний пример с Apache Commons Collections. HTTPoxy (сайт уязвимости) круче по радиусу поражения, так как это уязвимость не в софте, а в реализации интерфейса CGI. Это, например, стандартные библиотеки для языков программирования PHP, Go и Python, и соответственно, реализованные на них веб-приложения и скрипты. Таких существует огромное количество, как готовых, так и самописных, и лучшее решение — заблокировать возможность эксплуатации уязвимости для всего сразу, внеся изменения в конфиги Apache, NGINX, lighttpd и прочего софта.







А суть уязвимости довольно простая. В ситуации, когда требуется задать рабочему окружению в Linux прокси-сервер для доступа к сети, для этого часто используется переменная HTTP_PROXY. В некоторых реализациях интерфейса CGI описывается заголовок Proxy, который может быть передан серверу во время обмена данными, и на стороне сервера эта информация сохраняется в переменную HTTP_PROXY. Собственно все, проблема как раз конфликте имен, и это позволяет во многих ситуациях направлять данные через прокси-сервер, который был задан снаружи. Кем угодно, что ведет к атаке типа Man in the middle. Что интересно, спецификации на переменную нигде толком (например в документе RFC 3875) не прописаны. Решение очевидно: нужно заблокировать передачу такого заголовка. Но это для начала, а вообще надо править реализацию обработки данной переменной везде, где только можно.



Fun fact на закуску: уязвимости 15 лет. Впервые ее обнаружили и пофиксили в библиотеке libwww_perl в марте 2001 года. В апреле того же года исправили аналогичную проблему в утилите curl. В 2012 году избежали уязвимой реализации стандарта разработчики Ruby (и написали об этом в документации). В 13-м и 15-м годах, по данным исследователей HTTPoxy, компании VendHQ, проблема несколько раз всплывала на форумах и в почтовых рассылках. В одном случае топикстартер был настолько поражен банальностью беды, что добавил «наверняка я здесь что-то упустил». Но нет. Хорошая история про особое направление в безопасности: правильный сбор, обработка и интерпретирование доступной всем (годами!) информации.



Oracle закрывает 276 уязвимостей в своих продуктах

Новость.



В январе этого года Oracle выпустила рекордный кумулятивный патч, закрыв одним махом 248 уязвимостей. В июле рекорд побит с запасом: ежемесячный security-апдейт закрывает 276 уязвимостей в 84 продуктах. Зная, как сложно тестировать сразу много продуктов в разных сценариях, эту новость нужно безусловно оценить как в положительную, хотя в конце года вендор наверняка попадет в очередной некорректный список самых небезопасных разработчиков. Впрочем, выявленные проблемы от этого проще не становятся: из 276 уязвимостей 159 могут быть эксплуатированы удаленно, 19 (в девяти продуктах) оценены в 9,8 балла по шкале CVSS.





Впрочем, в Java, некогда самой часто атакуемой программе, а ныне уступившей сомнительное лидерство Adobe Flash, обнаружено и закрыто всего 13 уязвимостей, из них 9 с возможностью удаленной эксплуатации. Это третья на сегодня новость с эффектом «ложечки нашлись, осадочек остался». Oracle, конечно, молодцы. Но не думаю, что администраторы корпоративного софта Oracle будут сильно рады необходимости все бросить и накатывать столь гигантские патчи. А ведь придется.



Что еще произошло:

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



Закрыта уязвимость в сетевых устройствах Juniper.



В дарквебе нашли супердешевый троян-вымогатель, всего 39 долларов. С каждой жертвы требуют около 600 долларов и, что необычно, по истечении определенного времени начинают потихоньку удаляться зашифрованные файлы. Криминальный бизнес класса эконом.



Древности:

«V-1260»



Нерезидентный безобидный вирус-«призрак». Поражает .COM-файлы по алгоритму вирусов «Vienna». Зашифрован, при этом использует два интересных алгоритма. Первый алгоритм реализует свойство «призрака», благодаря чему два штамма этого вируса с большой вероятностью не будут совпадать ни на одном байте. Основное тело вируса шифруется в зависимости от таймера по 16777216 вариантам, а расшифровщик выбирается из более чем 3,000,000,000,000,000,000,000 вариантов (длина расшифровщика — 39 байт). Второй алгоритм достаточно успешно мешает трассировке вируса — используется динамическое рас/зашифрование кодов вируса при помощи int 1 и int 3.



Цитата по книге «Компьютерные вирусы в MS-DOS» Евгения Касперского. 1992 год. Страницa 90.



Disclaimer: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.
Original source: habrahabr.ru.

https://habrahabr.ru/post/306190/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Безопасность железных дорог из открытых источников

Пятница, 22 Июля 2016 г. 10:20 (ссылка)





Введение





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



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



В этой статье будет представлен обзор некоторых систем безопасности, которые могут применяться на современных высокоскоростных поездах. Количество таких платформ растет, они становятся все сложнее. При этом, они строятся на основе известных технологий, включая Ethernet, CAN, RS-485. Все чаще начинают применяться различные ПЛК и промышленные компьютеры под управлением ОС Windows/Linux/QNX. Кроме того, растет популярность систем, использующих радиоканал (как пример – GPS/ГЛОНАСС, GSM-R,Wi-FI).



В связи с этим возникает вопрос – безопасно ли создание огромной системы на основе «модулей», которые хорошо знакомы возможным злоумышленникам?





Как пример – потенциальные уязвимости в GSM-R. Конечно, кто-то возразит, что GSM и GSM-R — разные технологии. Однако, основное отличие между ними состоит в том, что зона покрытия в GSM составляет «круговую» площадь, в центре которой находится базовая станция. Стандарт GSM-R, в свою очередь, адаптирован для железных дорог таким образом, что зона покрытия простирается вдоль железной дороги. Важнее другое: все уязвимости, присутствующие в GSM, присущи и GSM-R, а эта технология активно используется для регулирования движения высокоскоростных поездов.



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



В современных поездах не обойтись и без Wi-Fi. Это, конечно, очень удобно для пассажиров, но не будем забывать, что стандарт IEEE 802.11 (проще говоря, Wi-Fi) хорошо известен злоумышленникам. Далее мы поговорим о том, что в настоящее время Wi-Fi/Ethernet начинает доминировать при построении TCN. Таким образом, при правильном стечении обстоятельств, может сложиться ситуация, когда злоумышленник, подключившись к Wi-Fi в вагоне, получит доступ и к другим узлам на шине MVB/WTB. А в ряде случаев данные узлы обладают очень неплохой производительной мощностью. Расшифровка упомянутых аббревиатур будет дана в разделе 1.1.



Еще один из возможных векторов атак – атаки на компьютеры, к которым подключается различное мобильное диагностическое оборудование, «наблюдающее» за работой всех деталей подвижного состава. И потому кажется не очень удачной идеей после каждой поездки отправлять поезд на диагностику по причине некорректной работы мобильного оборудования.



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



1. Общие сведения о современных высокоскоростных поездах





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



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



До появления распределенных систем автоматики, спутниковых систем логистика осуществлялась «вручную»: прежде чем отправить поезд, диспетчер звонил на следующую станцию и узнавал – свободен ли перегон, прошел ли предыдущий поезд.







Да и на поездах тех времен было не много систем, взаимодействующих между собой, машинистом и диспетчером.



С тех пор прошло достаточно времени, многое изменилось. Посмотрим, как выглядит сегодня современная железнодорожная инфраструктура.







На рисунке 1 показана взаимосвязь различных систем. Условно это «разнообразие» можно разделить на несколько категорий:


  • Диспетчерская автоматика;

  • Железнодорожная автоматика (бортовая);

  • Железнодорожная автоматика (путевая).





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



1.1. Применяемые стандарты




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

В 1999 году принят международный стандарт IEC 61375, который базируется на TCN – Train Communication Network. На момент принятия, TCN состоял из двух шин:


  • MVB – Multifunction Vehicle Bus – бортовая сеть единицы подвижного состава (это может быть вагон, локомотив);

  • WTB – Wire Train Bus – поездная сеть, объединяющая MVB части в единую систему управления поездом.





В 2014 году был принят новый стандарт, IEC 61375-2-5, который призван заменить WTB на ETB – Ethernet Train Backbone.



Пару слов о предпосылках создания ETCS – European Train Control System. В Европе популярен железнодорожный транспорт. Но в каждой стране есть свои стандарты обеспечения безопасности на железной дороге; кроме этого, имеются конструктивные отличия размещения различных датчиков, обеспечивающие аналогичные логические функции. Для безболезненного перехода на новый единый стандарт разработано несколько уровней.







1.1.1. ETCS первого уровня




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







1.1.2. ETCS второго уровня




ETCS второго уровня. Использование радиоканала для передачи координат и статуса поезда, разрешение на движение, данные о предстоящем блок-участке. Данные дублируются путевой автоматикой, в частности, на основе устройств контроля загруженности путей.





1.1.3. ETCS третьего уровня




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







1.2. Современная инфраструктура железной дороги




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







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







1.2.1. Шина WTB




В пределах вагона проложена MVB-шина, а поезд объединен в единую WTB-шину. Рассмотрим более детально ключевой функционал WTB-шины.

Основная задача – обеспечение единого информационного канала между различными единицами подвижного состава.







Для этого используются протоколы реального времени. Кроме того, WTB обеспечивает PDM – Process Data Marshalling, LFLD – Line Fault Location Detection, Network Management, Conformity arrangements. Англоязычные термины приводятся умышленно во избежание искажений.

Основные ограничения:


  • необходимость полной переадресации устройств (когда прицепляется или отцепляется вагон);

  • определенное число вагонов в составе (не более 22).





1.2.2. Шина MVB




В свою очередь, MVB-шина обеспечивает взаимодействие между различными датчиками, актуаторами и ПЛК. Используется архитектура master-slave. Причем допускается использование нескольких устройств типа “master” в сети.

Формат общения представлен на рисунке 8.







Master отправляет запрос, содержащий адрес устройства и код операции; slave-устройство — если к нему поступил запрос от мастера – отвечает.



1.2.3. Среда передачи данных




Для построения инфраструктуры MVB/WTB могут использоваться следующие среды передачи данных:


  • ESD (Electrical Short Distance). Обеспечивает связь на расстоянии порядка 20 метров, зачастую применяется для подключения устройств в одном корпусе;

  • EMD (Electrical Medium Distance). Используется для обеспечения связи на расстояниях порядка 200 метров, возможно подключение до 32 устройств;

  • OGF (Optical Glass Fibre) – расстояние порядка 2000 метров. Основное применение — там, где требуется высокая помехозащищённость (на локомотивах, например).





1.2.4. Применяемое оборудование




Теперь несколько слов хотелось бы сказать о классах MVB- устройств. Самые простые можно отнести к 1-му классу. В основном, они предназначены для подключения к датчикам и актуаторам. Устройства более высокого класса имеют CPU, их можно уже конфигурировать и программировать. Если заглянуть в техническое описание представленных устройств [8], [15], [16], [17] то увидим, что там могут использоваться Intel Atom N450, XScale IX435, ARM 9, Intel Core i7 и подобные процессоры. Объем оперативной памяти от 512 МБ до нескольких Гб. Работают под известными ОС (включая Windows, Linux, QNX). Для некоторых устройств возможна разработка программ на таких языках программирования, как «С» или «Perl».







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





2. Современная инфраструктура поезда





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







На данном рисунке представлено одно из реальных решений по построению MVB-шины, предлагаемых разработчиком. Как можно увидеть, к шине подключается огромное количество различных устройств, в том числе, HVAC система (1), функционал контроля различных параметров колесной тележки (2), имеются различные внешние коммуникации (12). Всем этим управляет бортовой компьютер (11).



2.1. Локомотивная телеметрическая система




Рассмотрим некоторые платформы, описание которых удалось найти в открытых источниках. Одна из них — Локомотивная телеметрическая система. Как можно увидеть на схеме, при построении данной системы используются широко распространенные протоколы, в том числе, CAN, Ethernet, RS-232, RS-485. Могут применяться промышленные Ethernet-коммутаторы.







2.1.1. Система «КЛУБ-У»




Одной из платформ, отвечающих за безопасность на перегоне, является система КЛУБ-У, состоящая из различных устройств. Основые функции, выполняемые данной системой [18]: исключение несанкционированного движения локомотива; сравнение фактической скорости с допустимой (при превышении допустимой скорости происходит включение сигнала «Внимание» и снятие напряжения с электромагнита ЭПК); контроль торможения перед запрещающим сигналом светофора; формирование сигналов для системы автоматического управления тормозами САУТ; контроль бдительности машиниста; регистрация параметров движения.







2.1.2. Система «АЛС»




«АЛС» — Автоматическая Локомотивная Сигнализация. В состав системы входят напольные передающие устройства, приёмные и дешифрующие девайсы на подвижном составе, а также устройства, согласующие работу АЛС с другими компонентами сигнализации и блокировки, индикаторы, датчики и исполнительные устройства на подвижном составе [19]. Входит в состав системы КЛУБ-У.







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



2.2. Система «Мониторинга тележек колесной пары»




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







2.3. Система учета пассажиропотока




Электронные билеты и электронная регистрация на поезд – этим мало кого можно удивить. Но высокоскоростные поезда в своем арсенале непременно имеют и систему учета и анализа пассажиропотока.







Как видно на рисунке 13, для реализации данной схемы применяются Ethernet-коммутаторы. Кроме этого, счётчики располагаются рядом с дверями, где злоумышленник может получить к ним доступ и подключиться к Ethernet-сети.



2.4. Система интервального регулирования движения




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

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







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



2.5. Диагностическое оборудование




Не стоит забывать и про различные системы диагностики, некоторые из которых представлены в мобильном исполнении.







Данное оборудование может эксплуатироваться в составе контрольно-проверочной аппаратуры (КПА) комплексных локомотивных устройств безопасности КЛУБ-У. Может имитировать сигналы включения устройств управления локомотивом, сигналы датчиков скорости, системы телеметрической системы контроля бдительности машиниста, сигналы АЛС.





3. Высокоскоростной поезд «Сапсан»





Выше был представлен небольшой перечень различных систем, которые могут использоваться на поездах. В частности, в России есть только один высокоскоростной поезд — «Сапсан», построенный на базе немецкого ICE. (Intercity-Express) [20]

На рисунке 16 можно увидеть функциональную схему системы управления поездом «Сапсан». И, как уже было сказано, она состоит из модулей MVB, которые объединяются в поездную шину WTB.







Система поезда построена на основе SIBAS 32.

Сама система SIBAS была разработана для железнодорожного транспорта еще в 1983 году немецкой компанией Siemens. В 1992 году SIBAS16 была модернизирована до SIBAS32, которая в настоящий момент применяется в таких поездах, как «Сапсан» и «Ласточка».

В 2008 году система была модернизирована до SIBAS PN, и ожидается, что первый поезд под управлением данной системы будет пущен в 2016 году. Основное различие между SIBAS 32 и SIBAS PN — в том, что SIBAS32 был основан на Intel 386/486 CPU с применением закрытой ОС SIBAS OS, в то время как SIBAS PN базируется на Power PC и Intel Atom CPU. В качестве среды разработки применяется Simatic Step 7.







Основные свойства SIBAS PN – модульность, соответствие промышленным стандартам, автоматическая адресация, независимость ПО от аппаратной платформы, наличие возможности регистрации и мониторинга через WEB-интерфейс.

Также отмечается независимость от аппаратной платформы, которая достигается за счет применения ОС жесткого реального времени VxWorks и WinAC. Хочется сразу подчеркнуть, что для VxWorks имеется ряд известных уязвимостей, и до 6 версии используется единое адресное пространство. Как показывает практика, на многих современных устройствах используются старые версии данной операционной системы, что может очень негативно сказываться на информационной безопасности.



4. Возможные векторы атак





Рассмотрев «начинку» современного поезда, настало время поговорить о возможных векторах атак.



4.1. Воздействие на радиосигналы (GSM-R, GPS)




Итак, что у нас есть в «арсенале». Как было сказано выше, для ведения поезда и передачи телеметрии используется GSM-R. Через этот канал связи передаются данные о координатах поезда, его скорости, осуществляется прием информации, связанной с подвижными блок-участками. А теперь представьте ситуацию, при которой на поезд поступает информация, что следующие несколько перегонов свободны, а по факту за «ближайшим поворотом» поезд нагоняет впередиидущий состав, т.к. в диспетчерском пункте имеются неверные данные о местонахождении впередиидущего поезда. Такой сценарий атаки нельзя назвать «фантастическим» в силу того, что принципиальных отличий между GSM и GSM-R нет. Как уже было сказано – основное отличие этих двух стандартов – зона покрытия. Для GSM она представлена как круговая площадь, в центре которой находится базовая станция, для GSM-R — простирается вдоль железной дороги. Помимо этого, согласно [4] требованиям, которые выдвигаются к GSM-R при построении ETCS, – должно обеспечиваться двойное перекрытие каждого участка, и, в случае сбоя радиосвязи, поезд должен переключаться в защитный режим вплоть до экстренного торможения.







Мы уже описали ситуацию, при которой столкновение поездов может произойти из-за того, что диспетчерский пункт получит неверные данные о местоположении поезда. Одним из способов выяснения текущих координат является использование GPS. Но данная технология имеет некоторые недостатки. Во-первых, сам сигнал достаточно слабый: зайдите в густую чащу леса или отойдите подальше от окна, и с большой вероятностью ваше устройство «потеряет» спутники. Другой, более важный момент, – возможна подмена самого сигнала, в результате чего бортовая автоматика поезда может посчитать, что находится в другом месте. Справедливости ради стоит отметить, что для определения местоположения поезда используется не только GPS/ГЛОНАСС.



4.2. Воздействие на путевую автоматику




Другим возможным вектором атак может служить различное воздействие на путевую автоматику, взаимодействующую с поездом. Как пример, потенциально возможно подключиться к «путевой системе» АЛС и получить доступ к внесению изменений в кодовые посылки импульсов.







В результате, будет сформирован сигнал, запрещающий проезд на следующий блок-участок. К этому может привести ложная остановка подвижного состава. Железная дорогая – это не автострада, где, если занята одна полоса, все спокойно, не спеша перестроятся в соседнюю полосу. На ЖД достаточно жесткий график движения поездов, особенно на загруженных участках, и непредвиденная остановка поезда может создать «транспортный» коллапс. В некоторых Европейских странах производится возврат до 100% стоимости билета в случае опоздания поезда более чем на 5 минут. [14]



4.3. Подключение к Ethernet/ Wi-Fi сети




Поскольку в современных поездах применяются такие технологии, как Ethernet и/или Wi-Fi, которые очень хорошо знакомы злоумышленникам, не стоит исключать и вариант подключения к Ethernet или к Wi-Fi и возможности переконфигурирования различных узлов на основе небезопасного протокола SNMP v1. Кроме того, не будем забывать, что у злоумышленника есть прямая возможность подключиться к инфраструктуре поезда, если применяется система анализа пассажиропотока и тем самым потенциально получить доступ к любому устройству сети.







Для снижения риска от такого рода атак – необходимо как минимум проводить сегментацию сети. Как было сказано ранее, некоторые узлы отличаются высокой производительной мощностью. Кроме того, как уже отмечалось, осуществляется переход от «зоопарка систем» к неким единым и «унифицированным» системам на основе архитектуры x86/ARM с применением известных операционных систем (Linux/Windows/QNX), которые, в свою очередь, имеют уязвимости. К сожалению, на промышленное оборудование, находящееся в эксплуатации, не всегда распространяются последние обновления и «заплатки», закрывающие найденные уязвимости.



4.4. Воздействие на системы автоматики поезда через диагностическое оборудование




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







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



4.5. Модификация прошивок на оборудовании




Не стоит забывать и про возможность модификации прошивок по пути следования оборудования от производителя до конечного заказчика.







Зачастую, помимо удаленных способов конфигурирования и настройки оборудования через специальное ПО, к «железу» можно получить непосредственный доступ, подключившись через RS-232. Далее, злоумышленник завладеет достаточно широкими возможностями по конфигурированию оборудования. Вплоть до обновления прошивки. Как показывает практика, зачастую отсутствует контроль подлинности прошивок оборудования. Это может обернуться тем, что атакующий подменит прошивку на самом низком уровне. В итоге, по поведению нельзя будет отличить исправное оборудование от зараженного до момента получения «критического» пакета данных.

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



5. Заключение





В качестве заключения, резюмируем основные выводы, к которым мы пришли в ходе анализа ситуации с безопасностью высокоскоростных поездов на основании открытых источников. Так, начинают доминировать широко известные технологии при построении TCN, включая Ethernet, Profinet. Можно наблюдать переход от закрытых архитектур к x86-подобной архитектуре. Идет переход от проприетарных ОС к широко известным ОС. Наблюдается увеличение объема передаваемой информации между поездом и другими системами и рост систем автоматики, отвечающей за безопасность и комфорт пассажиров.



Хочется отметить, что многие технологии, которые используются в современном высокоскоростном поезде, по отдельности уже хорошо изучены и «поломаны». Поезд представляет собой агрегацию таких технологий в единое целое, поэтому для реализации различного рода атак злоумышленникам придется «ломать» сразу несколько систем, учитывая специфику железной дороги. А вопрос о безопасности высокоскоростных поездов остается открытым.



Список литературы





Вот небольшой список открытых источников, из которых была почерпнута информация:



[1] Железнодорожный транспорт

[2] Высокоскоростной наземный транспорт

[3] Железнодорожная автоматика «Компоненты и системы железнодорожной автоматики компании «Сименс» для железных дорог «пространства 1520»

[4] «Высокоскоростное железнодорожное движение» Цикл лекций президента «Сименс» в России Дитриха Мёллера

[5] The Only Full-Range IRIS-Certified Product Portfolio for Railway Communication

[6] Change is Easy with New Technology to Upgrade Rolling Stock

[7] Mo Xia, Kueiming Lo, Shuangjia Shao, and Mian Sun “Formal Modeling and Verification for MVB”

[8] EKE “Technology for smarter trains”

[9] ИРЗ-Локомотив, Каталог продукции 2014

[10] SKF Решения для высокоскоростного железнодорожного транспорта.

[11] Автоматизированная система учета и анализа пассажиропотока

[12] Bombardier, «Продукты и решения для железнодорожного транспорта»

[13] Технические особенности высокоскоростного поезда Velaro Rus

[14] Renfe Memoria social

[15] IGW series Multiple Type Bus Gateway family

[16] Duagon, i101 A8 Based CPU Module

[17] Siemens, On-Board Products and Systems

[18] Описание аппаратуры комплексных устройств локомотивной безопасности

[19] Автоматическая локомотивная сигнализация

[20] German Railways
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/306182/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Промышленные системы управления — 2016: уязвимость и доступность

Пятница, 22 Июля 2016 г. 10:11 (ссылка)





Автоматизированные системы управления технологическими процессами (АСУ ТП, ICS) используются в наши дни повсеместно — от «умных домов» до атомных электростанций. Однако сложная организация таких систем, требование непрерывности технологического процесса и возможность доступа к АСУ ТП через всеобщий Интернет делают их легкоуязвимыми для хакерских атак.



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



Такие выводы содержатся в исследовании компании Positive Technologies, в котором проанализированы данные об уязвимостях АСУ ТП за период с 2012 по 2015 год, а также данные о доступности компонентов АСУ ТП через Интернет в 2015 году. Ниже представлены основные результаты этого исследования.



Методика исследования



В качестве основы для исследования была использована информация из общедоступных источников, таких как базы знаний уязвимостей (ICS-CERT, NVD, CVE, Siemens Product CERT, Positive Research Center), уведомления производителей, сборники эксплойтов, доклады научных конференций, публикации на специализированных сайтах и в блогах. Степень риска уязвимости компонентов АСУ ТП мы определяли на основе значения CVSS второй версии.



Сбор данных о доступности компонентов АСУ ТП в сети Интернет осуществлялся путем сканирования портов ресурсов, доступных в сети Интернет, с помощью общедоступных поисковых систем: Google, Shodan, Censys. После сбора данных был проведен дополнительный анализ на предмет взаимосвязи с АСУ ТП. Специалисты Positive Technologies составили базу данных идентификаторов АСУ ТП, состоящую примерно из 800 записей, позволяющих на основе баннера сделать заключение об используемом продукте и его производителе.



Результаты



В рамках исследования были рассмотрены уязвимости компонентов порядка 500 производителей автоматизированных систем управления. В итоге выявлено 743 уязвимости в АСУ ТП. Эксперты Positive Technologies в 2015 году самостоятельно обнаружили 7 новых уязвимостей (две из них имеют высокую степень риска), подробная информация о которых была направлена производителю.



Напомним, что согласно нашему предыдущему исследованию «Безопасность промышленных систем в цифрах», с 2009 по 2012 год количество обнаруженных уязвимостей АСУ ТП выросло в 20 раз (с 9 до 192). В последние годы (2012—2015) количество обнаруживаемых ежегодно уязвимостей остается стабильным (около 200). Это можно объяснить возросшим интересом производителей оборудования к своевременному выявлению и устранению уязвимостей и взаимодействию с исследователями.







Общее количество уязвимостей, обнаруженных в компонентах АСУ ТП



Лидерами в рейтинге наиболее уязвимых компонентов АСУ ТП являются продукты Siemens, Schneider Electric и Advantech. Однако количество обнаруженных уязвимостей зависит от распространенности продукта и от того, придерживается ли производитель политики ответственного разглашения. Как следствие, данный рейтинг не свидетельствует напрямую о защищенности конкретных решений того или иного производителя.







Количество уязвимостей в компонентах АСУ ТП различных производителей



Наибольшее количество уязвимостей было выявлено в SCADA-компонентах и программируемых логических контроллерах, сетевых устройствах промышленного назначения и инженерном ПО, а также в компонентах человеко-машинных интерфейсов и терминалах удаленного доступа и управления, что соответствует данным предыдущего отчета за 2012 год.



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







Распределение уязвимостей по степени риска



Поскольку данные о процессе устранения уязвимостей не публикуются, в исследовании использованы данные, полученные экспертами Positive Technologies непосредственно от производителей. Подробная информация о выявленных уязвимостях, которые уже устранены производителями, представлена на сайте компании. По данным 2015 года, лишь 14% уязвимостей устранены в течение трех месяцев, 34% устранялись более трех месяцев, а оставшиеся 52% ошибок — либо вовсе не исправлены, либо производитель не сообщает о времени устранения.







Доля устраненных уязвимостей в компонентах АСУ ТП



Вместе с тем в настоящее время только для 5% известных уязвимостей имеются опубликованные эксплойты. Данный показатель значительно снизился по сравнению с 2012 годом: тогда можно было найти эксплойты для 35% уязвимостей.



Наибольшее количество уязвимостей относятся к таким типам, как отказ в обслуживании (DoS), удаленное выполнение кода (Code Execution) и переполнение буфера (Overflow). Эксплуатация таких уязвимостей злоумышленником может привести к отказу в работе какого-либо оборудования или к его несанкционированной эксплуатации, что, учитывая требования к штатной работе АСУ ТП, недопустимо.







Распространенные типы уязвимостей компонентов АСУ ТП



По состоянию на март 2016 года обнаружено 158 087 компонентов АСУ ТП, доступных в сети Интернет. Наибольшее количество компонентов АСУ ТП доступно по протоколам HTTP, Fox, Modbus и BACnet, и в большинстве случаев для авторизации в таких системах используется словарный пароль.



Наибольшее число доступных компонентов АСУ ТП было найдено в США (43%), Германии (12%), Франции, Италии и Канаде (примерно по 5%). Низкое количество АСУ ТП, обнаруженных в Азии, связано с использованием локальных и малоизвестных на мировом рынке решений. Россия занимает 31 место с 600 доступными компонентами (это менее 1% общего числа найденных компонентов).







Число компонентов АСУ ТП, доступных в сети Интернет (по странам)



По распространенности компонентов АСУ ТП лидируют компании Honeywell (17%), SMA Solar Technology (11%), Beck IPC (7%). Самыми распространенными компонентами в сети Интернет являются системы для автоматизации зданий компании Tridium (25 264), входящей в состав группы компаний Honeywell, а также системы мониторинга и управления электроэнергией, в том числе на основе технологий солнечных батарей компании SMA Solar Technology (17 275).



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







Доля уязвимых и безопасных компонентов АСУ ТП, доступных через Интернет



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



Полный текст исследования «Безопасность АСУ ТП в цифрах — 2016» можно найти на www.ptsecurity.ru/research/analytics
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/306202/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Уязвимость HTTPoxy позволяет перенаправлять http-запросы веб-приложений

Четверг, 21 Июля 2016 г. 18:24 (ссылка)





18 июля была опубликована информация о наборе уязвимостей, получившем название HTTPoxy. Используя его, злоумышленники могут подменять переменную окружения HTTP_PROXY, что позволяет им перенаправлять http-запросы к веб-приложениям на свои ресурсы.



Уязвимость была выявлена при участии разработчика компании Vend Доменика Шайрлинка (Dominic Scheirlinck), который в своем блоге на Medium рассказал о том, как она была обнаружена его коллегами в ходе разбора одного из тикетов, поступившем в службу поддержки.



Как это работает



Шайрлинк подробно объясняет принцип работы HTTPoxy. Типичная атака с использованием этого набора уязвимостей выглядит так:




  1. Атакующий создает специально составленный HTTP-запрос, в котором содержится заголовок Proxy;

  2. CGI получает запрос и сохраняет значение заголовка в переменную среды HTTP_PROXY;

  3. CGI приложение запускает собственный веб-клиент, использующий переменную среды HTTP_PROXY в качестве настроек прокси;

  4. Клиент отправляет запрос, который вместо адреса назначения проксируется через сервер атакующего.



К примеру, так может выглядеть код эксплуатации на нескольких популярных языках:



PHP:



$client = new GuzzleHttp\Client();
$client->get('http://api.internal/?secret=foo')


Python:



from wsgiref.handlers import CGIHandler
def application(environ, start_response):
requests.get("http://api.internal/?secret=foo")
CGIHandler().run(application)


Go:



cgi.Serve(
http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
res, _ := http.Get("http://api.internal/?secret=foo")
// [...]


Более подробные PoC можно найти на GitHub в специальном репозитории HTTPoxy.



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



Согласно ему, в марте 2001 была обнаружена и исправлена ошибка некорректной обработки заголовков HTTP_PROXY в libwww-perl. В апреле того же года проблема была обнаружена в curl (и также исправлена, хотя и не для Windows). В 2012 году команда проекта Ruby разработала HTTP_PROXY для Net::HTTP — в их системе уязвимости не было.



В ноябре 2013 года она была упомянута в листе рассылки NGINX — пользователь Джонатан Мэттьюс описал ошибку, хотя и не был полностью уверен в своей правоте. В феврале 2015 года уязвимость также была упомянута в списке рассылке Apache httpd-dev. И уже в июле 2016 года сотрудник Vend Скот Джири (Scott Geary) обнаружил баг в реальной системе.



Какие системы уязвимы



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




  • CVE-2016-5386 Go

  • CVE-2016-5387 Apache HTTPD

  • CVE-2016-5388 Tomcat

  • CVE-2016-1000104 mod_fcgi

  • CVE-2016-1000105 Nginx cgi script

  • CVE-2016-1000107 Erlang HTTP Server

  • CVE-2016-1000108 YAWS

  • CVE-2016-1000109 HHVM FastCGI

  • CVE-2016-1000110 Python CGIHandler

  • CVE-2016-1000111 Python twisted



Как обнаружить уязвимость в своем софте



Специалисты компании RedHat разработали небольшой скрипт, позволяющий определить, уязвима ли конкретная система к HTTPoxy.



Для этого администратору сервера необходимо установить следующий CGI-скрипт и сделать его исполняемым:



test.cgi:
#!/bin/sh
echo "Content-Type:text/plain"

https://habrahabr.ru/post/306176/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<информационная безопасность - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda