Обзор эксплойтов

Крис Касперски

Хакер, номер #104, стр. 046

Еще не началась массовая миграция леммингов на Висту, а дыры в ней уже обнаруживаются косяками. Наш сегодняшний обзор вновь посвящен этой операционной системе, которая, вопреки всем заверениям корпорации Microsoft, намного более дырявая, чем предшествующая ей Xрюша.

Удаленный обход Windows Firewall

Brief

Начиная с XP в состав Windows входит некая пародия на брандмауэр а-ля Windows Firewall, блокирующая по умолчанию все локальные порты. Без существенных изменений она перекочевала в Висту. А там, в Висте, сетевой стек полностью переписан, заточена поддержка IPv6 с кучей тоннельных протоколов типа Teredo, инкапсулирующих IPv6 в IPv4/UDP и высаживающих брандмауэры сторонних производителей на полную измену, поскольку, чтобы определить целевой IP-адрес и порт назначения необходимо раздербанить пакет, декодируя его с учетом формата Teredo. О том, что Teredo представляет собой мощное орудие для пробивания уже существующих брандмауэров, всем специалистам и без того было известно. Но вот тот факт, что Teredo, разработанный Microsoft, обходит Windows Firewall, разработанный ей же, вызывал большой переполох — игнорируя настройки встроенного брандмауэра, хакеры получили возможность сканировать порты и устанавливать соединения с любыми сетевыми службами, используя штатные средства Висты. Дыра обнаружена двумя сотрудниками корпорации Symantec – Jim'ом Hoagland'ом и Ollie Whitehouse и подробно описана на www.securityfocus.com/bid/24779, а также в бюллетене безопасности от самой Microsoft, зарегистрированном под номером MS07-038. Впрочем, как обычно, из последнего ничего понять невозможно, поскольку все технические подробности там жестоко покоцаны.

Targets

Уязвимость затрагивает Microsoft Windows Vista beta 1/2, Home Basic/Home Premium/Business/Enterprise/Ultimate, включая и x64-битные редакции. На Windows 2000/XP и Server 2003 эта угроза не распространяется.

Exploit

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

Solution

Поскольку IPv6 все еще не получил большого распространения, то для предотвращения вторжения протокол Teredo рекомендуется отключить, например, путем блокирования TCP-порта 5357 на внешнем брандмауэре. Менее радикальная мера сводится к установке заплатки KB935807, которую можно скачать с сервера Windows Update.

Удаленный обход защиты кучи от переполнения

Brief

Массовые переполнения кучи начались со статьи «Once upon a free()...», опубликованной в августовском выпуске электронного журнала PHRACK за 2001 год. Microsoft напряглась и встроила в XP SP2 защиту от переполнения кучи, значительно усиленную в Висте, пробить которую удалось лишь совместными усилиями целой плеяды выдающихся хакеров: Brett'а Moore, Oded'а Horovitz'а, Matt'а Connover'а и нашего соотечественника Александра Сотирова. Сложность атаки объясняется тем, что Виста не только проверяет целостность служебных данных кучи (также называемых метаданными — metadata), но еще и шифрует их для надежности (кстати говоря, аналогичным образом поступает и библиотека glib для Linux и xBSD). Впрочем, ключ шифровки и контрольная сумма лежат рядом с подшефными метаданными, где они могут быть перезаписаны хакером. Достаточно «всего лишь» разобраться с форматом служебных данных.

Targets

Уязвимость затрагивает Microsoft Windows Vista beta 1/2, Home Basic/Home Premium/Business/Enterprise/Ultimate, включая и x64-битные редакции, а также Windows 2000/XP/Server 2003.

Exploit

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

fast = immlib.STDCALLFastLogHook( imm )

fast.logFunction( rtlallocate, 3)

fast.logRegister( "EAX" )

fast.logFunction( rtlfree, 3 )

fast.Hook()

Solution

Microsoft делает вид, что ничего не происходит, и никак не комментирует ситуацию, поэтому для защиты кучи приходится прибегать к продуктам сторонних производителей, например к коммерческому программному комплексу BufferShield, созданному на базе открытого проекта PaX. Ознакомительная 30-дневная версия BufferShield'а лежит на www.sys-manage.com/sites/D_BuffShld.html. Это действительно хорошее средство защиты от атак, направленных на переполняющиеся буферы.

Локальная атака на ACL'ы

Brief

В июне 2007 года хакер по имени Robbie Sohlman обратил внимание на «неаккуратную» установку в Висте прав, регламентирующих доступ к реестру и файловой системе. В результате нее непривилегированные пользователи могут беспрепятственно читать закрома защищенных хранилищ, в которых, помимо прочих данных, находится пароль администратора, а его захват приводит к известным последствиям. Хотя уязвимость носит локальный характер, ей могут пользоваться сетевые черви для повышения своих привилегий и установки руткитов, скрывая их от глаз антивирусных служб. Microsoft подсуетилась и выпустила заплатку, доступную через службу Windows Update. Технические подробности содержатся в бюллетене безопасности под номером MS07-032, из которого абсолютно невозможно ничего понять. То же самое относится и к прочим ресурсам по безопасности, например к Security Focus (www.securityfocus.com/bid/24411), ограничившемуся общими словами, но ничего не сказавшему по существу вопроса. Так что мне пришлось разбираться с проблемой самостоятельно. Анализ обновляемых файлов быстро выявил драйвер Fs_rec.sys, отвечающий за распознавание и автоматическое монтирование файловых систем, а также ряд модулей и системных библиотек: imagehlp.dll (библиотека для работы с PE-файлами), wmi.dll (инструментарий управления Windows – Windows Management Instrumentation) и upgclean.exe (компонент системы обновления). По-видимому, ошибки, относящиеся непосредственно к этой уязвимости, кроются в Fs_rec.sys, а остальные измененные файлы просто фиксят мелкие посторонние баги. Беглое дизассемблирование показало, что он также не при делах и реальную ответственность несет установщик Висты, ставящий слишком демократичные права на потенциально опасные файлы и ветви реестра, доступные штатными средствами операционной системы. В процессе наложения заплатки, помимо обновления непричастных к уязвимости файлов, меняется и политика прав доступа, что легко обнаружить путем сравнения образов файловой системы до и после латания дыры.

Targets

Уязвимость затрагивает Microsoft Windows Vista beta 1/2, Home Basic/Home Premium/Business/Enterprise/Ultimate, включая и x64-битные редакции. На Windows 2000/XP и Server 2003 эта угроза не распространяется.

Exploit

Не требуется — атака реализуется штатными средствами доступа к файловой системе и реестру.

Solution

Установить заплатку, которую можно получить на узле Windows Update.

Каскад дыр в Microsoft .NET 2

Под влиянием агрессивной политики маркетингового отдела Microsoft платформа .NET продолжает свое неуклонное наступление на рынок, потеснив классический Си++? и некоторые другие языки (Visual Basic, Java и т.д.). NET-библиотеки по умолчанию входят во все Windows-системы, начиная с XP (владельцам NT и W2K приходится их скачивать отдельно), а потому представляют собой весьма соблазнительную мишень для атаки, благо там есть, что атаковать. Сегодня мы рассмотрим как концептуальные уязвимости .NET'а, так и отдельные ошибки реализации, устраняемые путем установки соответствующей заплатки. Поскольку .NET представляет собой кросс-платформенную системно-независимую среду, абстрагированную от конкретной архитектуры, то даже крошечная уязвимость автоматически распространяется на миллионы машин, работающих по всему миру: от серверов и рабочих станций до домашних компьютеров.

Инъекция нулевых байт в текстовые строки

Язык .NET Common Language Runtime (сокращенно .NET CLR) поддерживает строки смешанного типа в MFC-стиле, трактующие символ нуля как обычный символ. В то же самое время native-функции языка Си воспринимают нулевой байт как завершитель строки, и потому при передаче CLR-строк функциям Native Си) возникает противоречие, подробно описанное в предыдущем обзоре эксплойтов.

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

Возьмем, например, метод String.Compare, сравнивающий ASCIIZ-строки, и сопоставим с оператором «=», сравнивающим CLR-строки, — налицо различие в поведении, наглядно демонстрируемое следующим ASP-приложением:

ASP-приложение, демонстрирующее разницу в поведении метода String.Compare и оператора «=», сравнивающих текстовые строки

Sub Page_Load()

dim allowed, sFirstItem, sSecondItem as string

sFirstItem = Request("first")

sSecondItem = Request("second")

response.Write ("String.Compare - First item = " & sFirstItem & "<br>")

response.Write ("String.Compare - Second item = " & sSecondItem & "<br>")

if String.Compare(sFirstItem, sSecondItem) =0 then

response.Write("String.Compare:Matched! Strs're the same"&"<br>")

else

response.Write("String.Compare:FAILED!Strs're not th esame"&"<br>")

End If

if sFirstItem=sSecondItem then

response.Write ("Direct eval - Matched! Strings are the same" & "<br>")

else

response.Write("Direct eval - FAILED! Strings are not the same"&"<br>")

End If

End Sub

Если передать приложению две полностью идентичных строки «test» («string.compare.demo.asp?first=test&second=test»), оно выдаст вполне ожидаемый и совершенно законный результат:

Результат сравнения строки «test» со строкой «test» методом String.Compare и оператором «=»

String.Compare - First item = test

String.Compare - Second item = test

String.Compare - Matched! Strings are the same

Direct Eval - Matched! Strings are the same

Но вот при передаче строк, включающих символ нуля (например, «string.compare.demo.asp?first=test%00&second=test»), ситуация кардинально изменится. Оператор «=» покажет различие, а метод String.Compare - нет:

Результат сравнения строки «test%00» со строкой «test» методом String.Compare и оператором «=»

String.Compare - First item = test?

String.Compare - Second item = test

String.Compare - Matched! Strings are the same

Direct Eval - Failed! Strings are not the same

Помимо String.Compare, подобной болезнью страдают Server.MapPath, System.Net.Mail.SmtpMail.Send, Server.Execute, Server.Transfer и многие другие методы. Проблема затрагивает Microsoft .NET Framework 1.0, Framework 1.0 SP1/SP2/SP3, Framework 1.1, Framework 1.1 SP1 и Framework 2.0. Для ее устранения Microsoft выпустила пару заплаток KB928365 (для Framework 2.0) и KB928366 (для .NET Framework 1.1), однако их установка приводит к изменению поведения встроенных методов и в ряде случаев к развалу ранее написанных приложений, которые также приходится обновлять.

Множественные переполнения буфера в JIT-компиляторе

Платформа .NET (как и Java) представляет собой интерпретатор байт-кода, заметно уступающий в быстродействии «чистым» Си-компиляторам. Поэтому для сокращения разрыва в производительности используется техника компиляции байт-кода в память, за что отвечает JIT-компилятор. Сгенерированный им код работает в обход виртуальной машины, игнорируя многочисленные проверки, что отнюдь не идет на пользу безопасности. Ни одной фирме так и не удалось реализовать JIT-компилятор для языка Java, полностью свободный от ошибок, так что платформа .NET в этом смысле не исключение. Механизмы, обеспечивающие защиту буферов от переполнения, ориентированы главным образом на виртуальную машину, обрабатывающую байт-код, и отсутствуют в машинной коде, сгенерированном JIT-компилятором (смотри статью в Википедии: http://en.wikipedia.org/wiki/Just-in-time_compilation).

Более того, JIT-компилятор также является весьма соблазнительным объектом для атаки, поскольку содержит множество ошибок переполнения, обнаруженных исследователем по имени Jeroen Frijters из компании Sumatra. Оказалось, что JIT-компилятор всецело полагается на обрабатываемый им байт-код, наивно рассчитывая на то, что он никем не изменен после трансляции. В Java, по крайней мере, имеется верификатор, тщательно проверяющий байт-код на соответствие спецификациям…

Для реализации DoS-атаки достаточно подать на вход JIT-компилятора слегка подпорченный файл с байт-кодом. Также возможен и удаленный захват управления, во всяком случае теоретически. Практически для этого потребуется обойти многочисленные защиты, предотвращающие выполнение машинного кода в неисполняемых областях памяти. В живой природе подобные эксплойты отсутствуют. А жаль! Ведь дыре подвержены практически все операционные системы линейки NT: от W2K до Висты. И хотя Microsoft уже выпустила соответствующие пакеты обновлений: www.microsoft.com/downloads/details.aspx?FamilyId=BA3CEB78-8E1B-4C38-ADFD-E8BC95AE548D (для Windows 2000) и www.microsoft.com/downloads/details.aspx?FamilyId=CBC9F3CF-C3C3 -45C4-82E3-E11398BC2CD2 (для Висты), далеко не все пользователи позаботились об их установке, и количество потенциальных жертв просто огромно.

Дополнительные технические подробности можно найти в бюллетене безопасности MS07-040 от Microsoft: www.microsoft.com/technet/security/Bulletin/MS07-040.mspx, а также на Security Focus'e: www.securityfocus.com/bid/24811.

Собственно говоря, PE-формат представляет собой весьма продвинутый контейнер для различных типов данных, и, чтобы не плодить сущности, Microsoft (в целях унификации) решила воспользоваться уже готовыми наработками, доверив это дело пионерам, допустившим в парсере PE-формата кучу ошибок. Причем среди них есть и фатальные — приводящие к переполнению с возможностью передачи управления на машинный код, что влечет за собой захват управления системой. И хотя угрозе присвоен статус «критической» (и она воздействует на все системы линейки NT, включая Висту), спешить с установкой заплаток нет никакой нужды — если у хакера есть возможность передать жертве исполняемый файл, который она запустит, то захват управления будет обеспечен и без переполнения. Исключение составляет, пожалуй, лишь CLR-код, передаваемый браузеру на выполнение. Тогда, чтобы подкинуть жертве трояна (или установить backdoor), достаточно заманить ее на специальным образом сконструированную web-страничку.

Подробнее об этой дыре можно прочитать на Security Focus'e: www.securityfocus.com/bid/24778.

Многочисленные ошибки фильтрации и SQL/HTML-инъекции

Техника SQL/HTML-инъекций отработана уже давно и вполне успешно. Допустим, при входе на некий сайт пользователь вводит свое имя и пароль, которые web-скрипт сравнивает с эталонными данными, извлеченными из базы. Взаимодействие с ней может быть организовано, например, так:

$result = mysql_db_query("database", "select * from userTable

where login = '$userLogin' and password = '$userPassword' ");

Здесь $userlogin — переменная с именем пользователя, а $userPassword — пароль, подставляемый в строку SQL-запроса. Если в теле имени или пароля присутствует парная закрывающая кавычка, то его остаток интерпретируется как последовательность SQL-команд. Посмотрим, что произойдет, если вместо пароля ввести строку «fuck' or '1'= '1». А произойдет при этом следующее. Базе данных будет послан запрос «select * from userTable where login = 'KPNC' and password = 'fuck' or '1' = '1'», в результате чего кавычка, стоящая после fuck'a, закроет пользовательский пароль, а остаток строки превратится в логическое выражение, обрабатываемое базой данных. Поскольку очень трудно представить себе ситуацию, при которой один не был бы равен одному, выражение всегда будет истинным вне зависимости от введенного пароля, в результате чего хакер сможет зайти на сайт под именем другого пользователя со всеми вытекающими отсюда последствиями.

Для предотвращения SQL/HTML-инъекций необходимо осуществлять фильтрацию всего пользовательского ввода на предмет наличия недопустимых символов, но разработчики web-приложений - люди ленивые, фильтрацию они реализуют кое-как, спустя рукава. Поэтому средства автоматической фильтрации, встроенные в платформу .NET, оказались большим подарком и завоевали всеобщую любовь и популярность. Между тем качество автоматического фильтра оставляет желать лучшего, он содержит множество ошибок, затрагивающих в том числе и Microsoft .NET Framework 2.0, входящий в состав «неуязвимой» Висты.

В частности, компания ProCheckUp (http://procheckup.com) обнаружила весьма солидный баг в системе управления контентом (.NET Content Management System, или сокращенно .NET CMS), допускающий подстановку .NET-скриптов в поле lang стандартного приложения logon.aspx, выполняемого в контексте уязвимого web-сайта, что позволяет реализовать атаку типа Cross Site Scripting путем отправки следующего GET-запроса:

GET-запрос к logon.aspx, подставляющий .NET-скрипт в поле lang

GET /logon.aspx?lang=<SCRIPT>alert('Can%20Cross%20Site%20Attack')</SCRIPT> HTTP/1.1

Host: example.host.co.uk

Cookie: ASINFO=...; ASP.NET_SessionId=...; CNBOOK=...; ASPSESSIONIDSCDAQTST=...

Referer: http://example.host.co.uk:80/environ.pl

User-Agent: Mozilla/4.0 (compatible;MSIE 5.5;Windows NT 5.0;T312461;.NET CLR 1.0.3705)

Connection: close