Добро пожаловать на независимую площадку Stop Malware.
Показано с 1 по 2 из 2

Тема: 2/3 энергетических компаний под угрозой Stuxnet-подобных атак

Понравилась статья? Поделись с друзьями!
  1. #1
    Аватар для Александр
    Александр
    Александр на форуме

    Администратор
    Регистрация
    21.03.2011
    Адрес
    Казахстан
    Сообщений
    5,421
    Поблагодарил(а)
    3,531
    Благодарностей
    2,028
    Записей в дневнике
    23

    2/3 энергетических компаний под угрозой Stuxnet-подобных атак

    Более 75% мировых энергетических компаний пострадали, по меньшей мере, от одной информационной бреши за последние 12 месяцев, причем 2/3 из них подвергают себя риску Stuxnet-подобных атак, поскольку они не применяют новейшие способы защиты Scada-систем, согласно новому исследованию Q1 Labs.

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

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



    "Одна из самых пугающих для меня вещей заключается в том, что в среднем требуется 22 дня, чтобы обнаружить инсайдеров, совершающих несанкционированные изменения. Это демонстрирует, насколько уязвимы сегодняшние организации", - заявил Ларри Понемон, основатель Ponemon Institute.

    "Эти результаты показывают, что энергетические и коммунальные организации пытаются определить проблемы, наносящие вред компании с точки зрения безопасности. Им необходимо преодолеть разрыв между бизнесом и ИТ, и сделать ИТ-безопасность одним из главных приоритетов организации".

    43% респондентов заявили, что злонамеренные инсайдеры были причиной информационных потерь номер один, но больше беспокоит то, что 67% не используют считающиеся "новейшими" технологии, чтобы снизить риск для Scada.

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

    С момента обнаружения в 2010 году червя Stuxnet, который, как считалось, был нацелен на ядерные заводы в Иране, потенциальные риски безопасности, связанные с системами Scada, оказались в центре внимания.

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


    Xakep.ru

  2. #2
    Аватар для Aibolit
    Aibolit
    Aibolit вне форума

    Администратор
    Регистрация
    22.03.2011
    Сообщений
    941
    Поблагодарил(а)
    690
    Благодарностей
    304
    Не много продолжу.

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

    Промышленный шпионаж

    Мы привыкли, что кибер преступность пытается обмануть, взломать и обворовать несчастных пользователей интернета. Но время всегда заставляет людей двигаться дальше, за новыми результатами и новой прибылью. То же самое происходит и в отношении плохих парней. Можно еще с десяток лет строить ботнеты, воровать номера CC, но ведь есть еще огромная неизведанная ниша — промышленность, ее технологии, секреты и ценные данные. Именно с ней и произошел инцидент в разгар лета — беспрецедентная атака на промышленные системы SCADA, Supervisory Control And Data Acquisition, что переводится как "Диспетчерское Управление и Сбор Данных" (по-нашему это аналог АСУ ТП — Автоматизированная Система Управления Технологическим Процессом). Такие системы контролируют процессы на производстве, нефтяных вышках, атомных электростанциях, газопроводах и т.д. Естественно, такие комплексы имеют свои базы данных, и та информация, что в этих базах, бесценна. Именно на эту информацию и нацелилась свежая вредоносная программа, получившая имя Stuxnet.


    Stuxnet

    Первыми обнаружили нового зверя братья-славяне из Белоруссии, а именно — антивирусная контора VirusBlokAda. 17 июня ими было найдено тело виря, но лишь к 10 июля они выпустили пресс-релиз (объясняя это тем, что им было необходимо уведомить компании, чье имя было в ходе дела "опорочено", и изучить экземпляр). Компании эти достаточно известны — Microsoft и Realtek. Специалисты VirusBlokAda зафиксировали использование червем 0day-уязвимости при обработке файлов ярлыков (.lnk), и поэтому в дело оказались вмешаны Microsoft. А вот при чем тут Realtek? Дело в том, что устанавливаемые червем драйвера имели действующий сертификат, заверенный Verisign и выданный на имя Realtek. Такой оборот дела сильно усложняет процесс детектирования вредоносного контента различными системами обнаружения и предотвращения вторжения на уровне хоста (HIPS, антируткиты), так как такие системы безгранично доверяют сертификатам, не обращая внимания на суть дела. Вполне уверен можно предположить, что доверенный сертификат сильно продлил жизнь "малваре", прежде, чем ее обнаружили. Как бы то ни было, после пресс-релиза белорусов, другие антивирусные компании так же подключились к исследованию, как новой уязвимости, с помощью которой распространялся червь, так и к боевой нагрузке.
    Распространение

    Механизм размножения червя, казалось бы, не особо-то и оригинальный — через USB-флешки. Но autorun.inf тут уже ни при чем. В дело вступает новая уязвимость, которая позволяет загружать произвольную .DLL-библиотеку, как только флешка будет вставлена, и пользователь откроет ее содержимое. Дело в том, что на флешке лежит .DLL-файл с вредоносным кодом (ну, фактически расширение, в случае с червем, — .TMP) и .LNK-файл. Файл с расширением .LNK является обычным ярлыком. Но в нашей ситуации ярлык не совсем обычный. При отображении ярлычка в стандартной оболочке или Total Commander автоматически выполнится лежащий рядом .DLL-файл со всеми вытекающими отсюда последствиями! Как такое могло произойти?

    Как известно, ярлык указывает на исполняемый файл и при двойном щелчке вызывает его. Но тут все без щелчков, да и .DLL-файл так не выполнить. Если рассмотреть ярлык в HEX-редакторе, можно увидеть, что в его середине указан путь до нашей .DLL. Кроме того, это не обычный ярлычок, а ярлычок на элемент панели управления! Эта-то деталь все и объясняет. Любой элемент панели управления — .CPL- апплет. Но CPL — это, по сути, простая .DLL, поэтому ярлык для панели управления особый, он как бы понимает, что имеет дело с .DLL. Кроме того, такой ярлык пытается ВЫТАЩИТЬ иконку из .DLL, чтобы отобразить ее в проводнике. Но для того, чтобы вытащить иконку, надо подгрузить библиотеку. Что, собственно, оболочка и делает с помощью вызова LoadLibraryW().

    Справедливости ради стоит отметить, что вызов этой функции автоматически влечет за собой выполнение функции DllMain() из подгружаемой библиотеки. Поэтому, если такой ярлычок будет указывать не на .CPL-апплет, а на злую библиотеку с кодом (в функции DllMain()), то код выполнится АВТОМАТИЧЕСКИ при просмотре иконки ярлыка.

    Кроме интересного метода распространения удивила и боевая нагрузка — никаких ботнетов, краж банковских паролей, номеров CC. Все оказалось куда масштабнее. Уязвимость .LNK провоцирует загрузку скрытого файла с именем ~wtr4141.tmp, лежащего рядом с ярлыком. Файл этот исполняемый, но маленький (всего 25 Кб). Как отметили специалисты из Symantec, очень важно на первых порах скрыть свое присутствие, пока система еще не заражена. С учетом специфики 0day-уязвимости, которая действует, как только пользователь увидит иконки, сработает и ~wtr4141.tmp, который в первую очередь вешает перехваты системных вызовов в kernel32.dll. Перехватываемые вызовы:

    * FindFirstFileW
    * FindNextFileW
    * FindFirstFileExW

    Хуки также вешаются и на некоторые функции из ntdll.dll:

    * NtQueryDirectoryFile
    * ZwQueryDirectoryFile

    Все эти функции обрабатываются со следующей логикой — если файл начинается с "~wtr" и заканчивается на ".tmp" (или на ".lnk"), то удалить его из возвращенного оригинальной функцией значения, а затем вернуть, что осталось. Другими словами, скрыть свое присутствие на диске. Поэтому пользователь просто не увидит файлы на флешке. После этого ~wtr4141.tmp подгружает второй файл с диска (~wtr4132.tmp). Делает он это не совсем стандартно, а не много извращенно — установкой хуков в ntdll.dll на вызовы:

    * ZwMapViewOfSection
    * ZwCreateSection
    * ZwOpenFile
    * ZwCloseFile
    * ZwQueryAttributesFile
    * ZwQuerySection

    Затем с помощью вызова LoadLibrary он пытается подгрузить несуществующий файл со специальным именем, на это дело срабатывают ранее установленные хуки и грузят второй файл, уже реально существующий — ~wtr4132.tmp, вернее, его не закодированную часть, которая раскодирует вторую часть (по факту — UPX-сжатие). Вторая часть представляет собой некие ресурсы, другие файлы, которые вступают в дело после расшифровки и экспорта (аналогичным извращенным методом с хуками на API функции).

    Первым делом устанавливаются два драйвера — mrxcls.sys и mrxnet.sys (именно из-за этих файлов червь получил такое название — Stuxnet). Устанавливаются они в системную директорию, а функционал на них — руткит уровня ядра с той же логикой, что и в первом файле. Это обеспечит защиту червя после перезагрузки и завершения процесса ~wtr4141.tmp.

    Драйвера эти, как уже было сказано, имеют легитимный сертификат Realtek, поэтому их установка пройдет без проблем (на данный момент сертификат уже отозван). Кроме руткита распаковываются файлы шаблона ярлыка и ~wtr4141.tmp для организации заражения других USB-устройств. Потом экспортируется код, который инъектируется в системные процессы и добавляет в реестр вышеотмеченные .SYS-файлы руткита (HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\M RxCls). Далее раскодируются два .DLL-файла, которые заменяют существующие файлы системы SCADASiemens Step 7.

    Таким образом, все вызовы из системы SCADA переходят в поддельные библиотеки. Там происходит "нужная" обработка, после чего вызовы передаются в оригинальные .DLL (остальную часть функций вирь и вовсе эмулирует самостоятельно). Кроме всего перечисленного, червь блокирует процессы антивирусов и пытается найти сервера СУБД (MSSQL). Найдя таковые, он пробует выполнить вход с учетной записью WinCCConnect и паролем по умолчанию — 2WSXcder. Это учетная запись от БД SCADA типа Siemens Simatic WinCC. Как видно, червь заточен именно под продукт Siemens. Если аутентификация прошла успешно, шпион выкачивает данные о процессах и прочую секретную информацию. Кроме того, он не отказывается поискать в локальных файлах полезную для шпионов информацию. Если удается обнаружить выход в интернет, то червь лезет на один из командных серверов. Имена серверов такие:

    * mypremierfutbol.com
    * todaysfutbol.com


    Туда червь и пытался достучаться и "что-то" слить в зашифрованном виде. Ребята из Symantec разобрались и с этой задачей. Оказалось, что шифрование представляет собой побайтовую операцию XOR с 31-битным ключом, который был прошит в одной из .DLL-библиотек. Ответ с сервера также приходит в XOR-виде, правда, используется уже другой ключ из той же библиотеки. Троян отсылает на сервер общую информацию о зараженной машине (версия винды, имя компьютера, адреса сетевых интерфейсов, а также флаг наличия SCADA). В ответ от командного центра могут приходить вызовы RPC для работы с файлами, создания процессов, внедрения в процесс и загрузки новых библиотек и др.


    Что это было?

    Именно так… что же это было?! Данные из SCADA-систем интересны лишь конкурентам. Конкурентам в коммерческом или политическом планах. Если взглянуть на карту распространения заразы (по данным лаборатории Касперского), то видно, что эпицентр — Азия (а именно — Индия, Иран и Индонезия). Если взглянуть на описанный функционал червя, то можно ужаснуться — контроль над .DLL и перехват функций SCADA. Разве не плохо — управлять индийской атомной электростанцией по интернету? Или проникнуть в иранскую ядерную программу? К тому же, мы имеем факт, что драйвера руткита имеют легальный сертификат, который географически принадлежит компании, базирующейся в той же зоне (в Тайланде)!

    После всего случившегося, возникнет неслабый интерес к безопасности SCADA. До этого инцидента уже были и исследователи, и фирмы, которые предупреждали о проблемах в безопасности и предлагали свои услуги, но этот конкретный случай может помочь им очень неплохо заработать. Такая же модель червя годится и для ERP-систем, так как показанная схема применима и для этой модели. ERP-системы отвечают за планирование и управление бизнесом — деньгами, задачами, товарами и т.д., и т.п. (Я бы даже сказал, что написать такого червя под ERP было бы легче, но раз была выбрана SCADA и регионы Азии. Но вот что касается .LNK-уязвимости, то, например, троянец Zeus уже стал использовать ее для своего размножения.

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

    Источник xaker.ru

  3. 1 пользователь сказал cпасибо Aibolit за это полезное сообщение:

    Александр (09.04.2011)

 

 

Похожие темы

  1. OpenOffice.org под угрозой закрытия ищет источники финансирования
    от SMLF news BOT в разделе СОФТвенные новости
    Ответов: 0
    Последнее сообщение: 15.10.2011, 00:23

Социальные закладки

Социальные закладки

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •