Имеется информация о том, что сайт www.ms-dynamics.ru используется для атак на компьютеры пользователей.

[gl00mie]

В продолжение темы "атак на компьютеры пользователей"... Читая один не относящийся к тематике форума блог, обнаружил там упоминание о занимательной дыре в MSIE. Вот выдержка из упомянутого в блоге доклада Alexander Sotirov & Mark Dowd Bypassing Browser Memory Protections в вольном переводе (стр.33):

Цитата:

MSIE версии 6 и выше позволяет внедрять в страницы элементы управления .NET (иногда именуемые элементами пользовательского интерфейса - UI Controls). Эти элементы управления являются бинарными файлами .NET, которые выполняются в "песочнице" (т.е. в ограниченной контролируемой среде) внутри процесса браузера и могут восприниматься как .NET-эквивалент Java-апплетов, либо как более безопасная замена элементов управления ActiveX. Загружаются эти элементы управления браузером за счет использования тега <OBJECT>:

PHP код:

<OBJECT classid="ControlName.dll#Namespace.ClassName"> 


Синтаксис схож с тем, как внедряются элементы ActiveX, но есть несколько ключевых отличий:

• Вместо GUID атрибут classid содержит URL, указывающий на местоположение исполняемого файла .NET, а также пространство имен и название класса для элемента управления.
• В конфигурации MSIE по умолчанию элементы управления .NET могут быть внедрены в любой странице в зоне Internet. Это поведение можно изменить через закладку настройки безопасности MSIE.
• В отличие от ActiveX, не выводится никаких предупреждений, когда браузер встречает неизвестный прежде элемент управления .NET. Это связано с тем, что такие элементы управления выполняются в "песочнице" и рассматриваются как безопасные независимо от места своего происхождения, подобно тому как рассматриваются Java-апплеты.

Библиотеки .NET являются PE-файлами с дополнительным заголовком, описывающим классы и .NET байткод, содержащийся в библиотеке. Байткод является скомпилированным кодом на Intermediate Language (IL), выполняемым виртуальной машиной Common Language Runtime (CLR). Когда библиотека .NET загружается в браузер, средой выполнения проверяется, что она содержит только IL-код и не содержит исполняемого кода, который бы мог выполняется непосредственно процессором. Фактически же выполняется довольно обширный набор проверок с целью удостовериться, что загружаемый файл является корректным.
Однако, поскольку формат библиотек .NET по структуре является надмножеством формата PE-файлов, CLR отображает их в память как обычные исполняемые файлы. Это значит, что ядро разбирает PE-заголовок и загружает все секции в память точно так же, как и для обычных исполняемых файлов или DLL-библиотек. По ходу этого процесса ядро устанавливает разрешения для каждой секции в соответствии с флагами, прописанными для нее в PE-заголовке. Если бинарный файл содержит исполняемую секцию (т.е. секцию с соответствующим флагом в заголовке), то она будет загружена в память, и ее страницы будут помечены как исполняемые. Все это дает возможность злоумышленнику поместить исполняемый код оболочки в секцию .text (обычное название для секции кода исполняемых файлов, собираемых Microsoft'овским компоновщиком) библиотеки .NET и сделать так, что этот код будет загружен в помеченные как исполняемые страницы памяти в контексте процесса браузера. В Windows XP адрес, по которому будет загружен исполняемый файл, зависит от значения image base, указанного в PE-заголовке этого файла, которое также контролируется злоумышленником.
Возможность разместить исполняемый код оболочки по известному адресу в адресном пространстве обычно имеет первостепенное значение в успешном использовании уязвимости, связанной с нарушением содержимого памяти. Использование элементов управления .NET для размещения такого кода по ряду причину чрезвычайно полезной для злоумышленников:

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

Мы можем, к примеру, поместить код оболочки в строку, используемую в конструкторе класса нашего элемента управления. Эта строка будет помещена в секции .text нашей .NET библиотеки и будет помечена как исполняемый код, когда наш компонент окажется загруженным. Эксплойт может использовать переполнение буфера ANI для того, чтобы перенаправить адрес возврата на указанный код и выполнить его.

Проверил сейчас настройки безопасности для зоны Internet в MSIE7 на своем рабочем компе - для .NET-компонент, не подписанных с помощью Authenticode, в настройках запуска стоит "разрешить", т.е. внедряй в страничку что хочешь - MSIE это все тихо-мирно загрузит и запустит у меня на компе