Различия

Здесь показаны различия между двумя версиями данной страницы.

Ссылка на это сравнение

articles:exploits-review-0x0e [2017/09/05 02:55] (текущий)
Строка 1: Строка 1:
 +====== exploits-review-0x0E ======
 +<​sub>​{{exploits-review-0x0E.odt|Original file}}</​sub>​
 +
 +====== exploits review\\ 0Eh выпуск ======
 +
 +крис касперски ака мыщъх, a.k.a. nezumi, a.k.a elraton, a.k.a. souriz, no-email
 +
 +**еще не началась массовая миграция леммингов на Вислу, а дыры в ней уже обнаруживаются косяками. наш сегодняшний обзор вновь посвящен этой операционной системе,​ которая,​ вопреки всем заверениям корпорации ****Microsoft ****намного более дырява,​ чем предшествующая ей ****X****рюша.**
 +
 +**{{exploits-review-0x0e_Image_0.jpg?​553}}**
 +
 +Рисунок 1 вот такая она эта загадочная и неповторимая Виста, которую возможно создать лишь однажды
 +
 +===== удаленный обход Windows Firewall =====
 +
 +**brief**:​начиная с XP,в состав Windows входит некая пародия на брандмауэр а-ля Windows Firewall, блокирующая по умолчанию все локальные порты и без существенных изменений перекочевавшая в Висту. А там, в Висте, сетевой стек полностью переписан,​ заточена поддержка IPv6 с кучей тоннельных протоколов типа Teredo, инкапсулирующих IPv6 в IPv4/UDP, и высаживающих брандмауэры сторонних производителей на полную измену,​ поскольку,​ чтобы определить целевой IP-адрес и порт назначения необходимо раздербанить инкапсулировать пакет, декодируя его с учетом формата Teredo. О том, что Teredo представляет собой мощное орудие для "​пробивания"​ уже существующих брандмауэров,​ всем специалистам и без того было известно (см. например,​ мыщъхиную статью "​глубины и вершины сетевого стека висты",​ опубликованную в "​хакере-спец"​),​ но вот тот факт, что Teredo, разработанный Microsoft, обходит Windows Firewall, разработанный ей же, вызывал большой переполох — игнорируя настройки строенного брандмауэры хакеры получили возможность сканировать порты и устанавливать соединения с любыми сетевыми службами,​ используя штатные средства Висты (достаточно послать жертве письмо со ссылкой на IPv6-адрес и Windows автоматически активирует протокол Teredo, который по умолчанию дезактивируется через 60 минут неактивности). Дыра обнаружена двумя сотрудниками корпорации Symantec – Jim'​ом Hoagland'​ом с Ollie Whitehouse и подробно описана на http://​www.securityfocus.com/​bid/​24779,​ а так же в бюллетене безопасности от самой Microsoft, зарегистрированным под номером MS07-038 (http://​www.microsoft.com/​technet/​security/​Bulletin/​MS07-038.mspx),​ впрочем,​ как обычно из последнего ничего понять невозможно,​ т.к. все технические подробности там жестоко покоцаны;​
 +
 +**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, которую можно скачать с сервера WindowsUpdate;​
 +
 +{{exploits-review-0x0e_Image_1.jpg?​553}}
 +
 +Рисунок 2 внешний вид Windows Firewall
 +
 +===== удаленный обход защиты кучи от переполнения =====
 +
 +**brief**:​массовые переполнения кучи начались со статьи "Once upon a free()...",​ опубликованной в августовском выпуске электронного журнала "​PHRACK"​ за 2001 год. Microsoft напрягалась и встроила в XP SP2 защиту от переполнения кучи, значительно усиленную в Висте, пробить которую удалось лишь совместными усилиями целой плеяды выдающихся хакеров:​ Brett'​а Moore, Oded'​а Horovitz'​а,​ Matt'​а Connover'​а и нашего соотечественника Александра Сотирова. Сложность атаки объясняется тем, что Виста не только проверяет целостность служебных данных кучи (так же называемых метаданными — metadata), но еще и шифрует их для надежности (кстати говоря,​ аналогичным образом постает и библиотека glib для Linux и xBSD). Впрочем,​ ключ шифровки и контрольная сумма лежат рядом с "​подшефными"​ метаданными,​ где они могут быть перезаписаны хакером. Достаточно "​всего лишь"​ разобраться с форматом служебных данных и "​зеленый"​ билет у нас в кармане. На сингапурской конференции BlackHat-2007,​ Nicolas Waisman (nicolas@immunityinc.com) из исследовательской компании Immunityinc прочла доклад "​Understanding and bypassing Windows Heap Protection"​("​Понимание и обход защиты от переполнения кучи в Windows"​),​ текст которого можно найти на http://​www.immunityinc.com/​downloads/​Heap_Singapore_Jun_2007.pdf,​ а так же продемонстрировала хакерский инструментарий,​ созданный в лаборатории Immunityinc специально для атаки на кучу, распространяющийся на коммерческой основе:​ http://​www.immunityinc.com/​products-canvas.shtml;​
 +
 +**targets**:​уязвимость затрагивает Microsoft Windows Vista beta 1/2, Home Basic/Home Premium/​Business/​Enterprise/​Ultimate,​ включая в том числе и x64-битные редакции,​ а так же Windows 2000/​XP/​Server 2003;​
 +
 +**exploit**:​для реализации атаки можно использовать библиотеку Immlib, созданную компанией Immunityinc Inc для своего же отладчика ImmunityincDebugger. Исходный текст демонстрационного скрипа,​ пробивающего защиту кучи от переполнения,​ приведен ниже:
 +
 +fast = immlib.STDCALLFastLogHook( imm ) 
 +
 +fast.logFunction( rtlallocate,​ 3)
 +
 +fast.logRegister( "​EAX"​ )
 +
 +fast.logFunction( rtlfree, 3 )
 +
 +fast.Hook()
 +
 +Листинг 1 скрипт для Immunityinc Debugger, обходящий защиту кучи в Windows Виста от переполнения
 +
 +**solution**:​Microsoft делает вид, что ничего не происходит и никак не комментирует ситуации,​ поэтому для защиты кучи приходится прибегать к продуктам сторонних производителей,​ например,​ к коммерческому программному комплексу BufferShield,​ созданному на базе открытого проекта PaX (www.ngsec.com/​ngproducts/​stackdefender/​). Ознакомительная 30-ти дневная версия BufferShield'​а лежит на http://​www.sys-manage.com/​sites/​D_BuffShld.html. Это действительно хорошее средство для защиты от атак, направленных на переполняющиеся буфера.
 +
 +{{exploits-review-0x0e_Image_2.png?​552}}
 +
 +Рисунок 3 внешний вид отладчика коммерческого Immunityinc Debugger, подозрительно похожего на некоммерческий OllyDbg
 +
 +===== локальная атака на ACL'ы =====
 +
 +**brief**:​в июне 2007 года хакер по имени Robbie Sohlman обратил внимание на "​неаккуратную"​ установку прав в Висте, регламентирующих доступ к реестру и файловой системе,​ в результате чего непривилегированные пользователи могут беспрепятственно читать закрома защищенных хранилищ,​ в которых помимо прочих данных находится пароль администратора,​ захват которого приводит к известным последствиям. Хотя уязвимость носит локальный характер,​ ей могут пользоваться сетевые черви для повышения своих привилегий и установке root-kit'​ов,​ скрывающих их от глаз антивирусных служб. Microsoft подсветилась и выпустила заплатку,​ доступную через службу Windows Update. Технические подробности содержаться в бюллетене по безопасности под номером MS07-032 (http://​www.microsoft.com/​technet/​security/​Bulletin/​MS07-032.mspx) из которого ровным счетом понять ничего не возможно. Тоже самое относится и к прочим ресурсам по безопасности,​ например,​ к Security Focus:​ http://​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.
 +
 +{{exploits-review-0x0e_Image_3.png?​553}}
 +
 +Рисунок 4 скудная информация о дыре в ACL'​ах на сайте Security Focus
 +
 +===== full disclose\\ каскад дыр в Microsoft .NET 2 =====
 +
 +Под влиянием агрессивной политики маркетингового отдела Microsoft платформа .NET продолжает свое неуклонное наступление на рынок, потеснив классический Си++ и некоторые другие языки (Visual Basic, Java, etc). NET-библиотеки по умолчанию входят во все Windows-системы,​ начиная с XP (владельцам NT и W2K приходится их скачивать отдельно),​ а потому представляют собой весьма соблазнительную мишень для атаки, благо там атаковать есть что. Сегодня мы рассмотрим как концептуальные уязвимости .NET'​а,​ так и отдельные ошибки реализации,​ устраняемые путем установки соответствующей заплатки. Поскольку,​ .NET представляет собой кросс платформенную системно-независимую среду, абстрагирующуюся от конкретной архитектуры,​ то даже крошечная уязвимость автоматически распространяется на миллионы машин, работающих по всему миру — от серверов и рабочих станций до домашних компьютеров.
 +
 +
 +
 +{{exploits-review-0x0e_Image_4.jpg?​552}}
 +
 +Рисунок 5 конференция по безопасности платформы .NET в Бостоне – одна из многих…
 +
 +==== инъекция нулевых байт в текстовые строки ====
 +
 +Язык .NET Common Language Runtime (сокращенно .NET CLR) поддерживает строки смешенного типа в MFC-стиле,​ трактующие символ нуля как обычный символ. В то же самое время, native-функции языка Си воспринимают нулевой байт как завершитель строки и потому при передаче CLR-строк native-Си функциям возникает противоречие,​ подробно описанное в предыдущем обзоре exploit'​ов.
 +
 +Но, если в нормальных языках ответственность за некорректное преобразование типа целиком лежит на совести программиста,​ вызывающего функции внешних библиотек без дополнительных проверок,​ то в случае с .NET мы имеем грабли даже при использовании встроенных методов,​ разработчики которых так и не смогли определиться какой строковой тип они должны поддерживать.
 +
 +Возьмем,​ например,​ метод String.Compare,​ сравнивающего ASCIIZ-строки,​ и сопоставим его оператору "​=",​ сравнивающего CLR-строки — налицо различие в поведении,​ наглядно демонстрируемое следующим ASP-приложением:​
 +
 +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
 +
 +Листинг 2 ASP-приложение,​ демонстрирующее разницу в поведении метода String.Compare и оператора "​="​ сравнивающих текстовые строки
 +
 +Если передать приложению две полностью идентичных строки "​test"​ (string.compare.demo.asp?​first=test&​second=test),​ оно выдаст вполне ожидаемый и совершенно законный результат:​
 +
 +String.Compare - First item = test
 +
 +String.Compare - Second item = test
 +
 +String.Compare - Matched! Strings are the same
 +
 +Direct Eval - Matched! Strings are the same
 +
 +Листинг 3 результат сравнения строки "​test"​ со строкой "​test"​ методом String.Compare и оператором "​="​
 +
 +Но вот при передаче строк, несущих на своем борту символ нуля (например,​ "​string.compare.demo.asp?​first=test%00&​second=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
 +
 +Листинг 4 результат сравнения строки "​test%00"​ со строкой "​test"​ методом String.Compare и оператором "​="​
 +
 +Помимо 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), однако их установка приводит к изменению поведения встроенных методов и в ряде случаев приводит к развалу ранее написанных приложений,​ которые так же приходится обновлять.
 +
 +{{exploits-review-0x0e_Image_5.png?​553}}
 +
 +Рисунок 6 демонстрация уязвимости в .NET'​е
 +
 +==== множественные переполнения буфера в JIT-компиляторе ====
 +
 +Платформа .NET (как и Java) представляет собой интерпретатор байт-кода,​ заметно уступающий в быстродействии "​чистым"​ Си-компилятором и потому для сокращения разрыва в производительности используется техника компиляции байт-кода в память,​ за что отвечает JIT-компилятор. Сгенерированный им код работает в обход виртуальной машины,​ игнорируя многочисленные проверки,​ что отнюдь не идет на пользу безопасности. Ни одной фирме так и не удалось реализовать JIT-компилятор для языка Java, полностью свободный от ошибок,​ так что платформа .NET в этом смысле не исключение. Механизмы,​ обеспечивающие защиту буферов от переполнения,​ главным образом ориентированы на виртуальную машину,​ обрабатывающую байт-код и отсутствуют в машинной коде, сгенерированным JIT-компилятором (подробнее см. статью на Википедии:​ http://​en.wikipedia.org/​wiki/​Just-in-time_compilation)
 +
 +{{exploits-review-0x0e_Image_6.png?​552}}
 +
 +Рисунок 7 JIT-компиляторы на Википедии
 +
 +Более того, JIT-компилятор так же является весьма соблазнительным объектом для атаки, поскольку содержит множество ошибок переполнения,​ обнаруженных исследователем по имени Jeroen Frijters из компании Sumatra. Оказалось,​ что JIT-компилятор всецело полагается на обрабатываемый им байт-код,​ наивно полагая,​ что он никем не изменен после трансляции. В Java по крайней мере имеется верификатор,​ тщательно проверяющий байт-код на соответствие спецификациям…
 +
 +Для реализации DoS атаки достаточно подать на вход JIT-компилятора слегка подпорченный файл с байт-кодом. Так же возможен и удаленный захват управления во всяком случае теоретически. Практически — для этого потребуется обойти многочисленные защиты,​ предотвращающие выполнение машинного кода в неисполняемых областях памяти. В живой природе подобные exploit'​ы отсутствуют… А жаль! Ведь дыре подвержены практически все операционные системы линейки NT – от W2K до Висты и хотя Microsoft уже выпустила соответствующие пакеты обновлений http://​www.microsoft.com/​downloads/​details.aspx?​FamilyId=BA3CEB78-8E1B-4C38-ADFD-E8BC95AE548D (для Windows 2000) и http://​www.microsoft.com/​downloads/​details.aspx?​FamilyId=CBC9F3CF-C3C3 -45C4-82E3-E11398BC2CD2 (для Вситы) далеко не все пользователи позаботились об их установке и количество потенциальных жертв просто огромно.
 +
 +Дополнительные технически подробности можно найти в бюллетене безопасности MS07-040 от Microsoft: http://​www.microsoft.com/​technet/​security/​Bulletin/​MS07-040.mspx,​ а так же на Security Focus'​e:​ http://​www.securityfocus.com/​bid/​24811
 +
 +==== >>>​ врезка переполнение буфера в загрузчике PE-файлов ====
 +
 +.NET трансляторы позволяют компилировать приложения в псведо-исполнеямые файлы формата PE. "​Псевдо"​ — потому что байт-код,​ насильно засунутый в exe-файл,​ остается интерпретируемым байт-кодом и без .NET-платформы работать ни за что не будет, хоть бейся головой об стену, хоть убейся об газель,​ хоть грызи ее зубами (хинт: везде в маршрутках висит табличка с надписью "​место для удара головой",​ о которое и предполагается убиться).
 +
 +Собственно говоря,​ PE-формат представляет собой весьма продвинутый контейнер для различных типов данных,​ и чтобы не плодить сущности,​ Microsoft (в целях унификации) решила воспользоваться уже готовыми наработками,​ доверив это дело пионерам,​ допустившим в парсере PE-формата тучу ошибок,​ среди которых есть и фатальные — приводящие к переполнению с возможностью передачи управления на машинный код, что влечет за собой захват управления системой. И хотя угрозе присвоен статус "​критической"​ (и она воздействует на все системы линейки NT, включая Висту),​ спешить с установкой заплаток нет никакой нужны — если у хакера есть возможность передать жертве исполняемый файл, который она запустит,​ то захват управления будет обеспечен и без переполнения.Исключение составляет,​ пожалуй,​ лишь CLR-код, передаваемый браузеру на выполнение. Тогда, чтобы подкинуть трояна жертве (или установить backdoor) достаточно заманить ее на специальным образом сконструированную Web-страничку.
 +
 +Подробнее об этой дыре можно прочитать на Security Focus'​e:​ http://​www.securityfocus.com/​bid/​24778.
 +
 +==== многочисленные ошибки фильтрации и SQL/HTML инъекции ====
 +
 +Техника SQL/​HTML-инъекций отработана уже давно и вполне успешно. Допустим,​ при входе на некоторый сайт пользователь вводит свое имя и пароль,​ которые web-скрипт сравнивает с эталонными данными,​ извлеченными из базы, взаимодействие с которой может быть организовано,​ например,​ так:
 +
 +$result = mysql_db_query("​database",​ "​select * from userTable
 +
 +where login = '​$userLogin'​ and password = '​$userPassword'​ ");
 +
 +Листинг 5 типичный пример запроса к SQL-базе
 +
 +Здесь: $userlogin — переменнаяс именем пользователя,​ а $userPassword — пароль,​ подставляемые в строку SQL-запроса. Если в теле имени или пароля присутствует парная закрывающая кавычка,​ то его остаток интерпретируется как последовательность SQL-команд. Посмотрим,​ что произойдет,​ если вместо пароля ввести строку "​fuck'​ or '​1'​= '​1"​. А произойдет при этом следующее. Базе данных будет послан запрос "​select * from userTable where login = '​KPNC'​ and password = '​fuck'​ or '​1'​ = '​1'",​ в результате чего кавычка,​ стоящая после fuck'​a,​ закроет пользовательский пароль,​ а остаток строки превратится в логическое выражение,​ обрабатываемое базой данных. Поскольку очень трудно представить себе ситуации при которой один не был бы равен одному,​ то выражение всегда окажется истинным — вне зависимости от введенного пароля,​ в результате чего хакер сможет зайти на сайт под именем другого пользователя со всеми вытекающими отсюда последствиями.
 +
 +{{exploits-review-0x0e_Image_7.png?​552}}
 +
 +Рисунок 8 ролик,​ демонстрирующий технику SQL-впрыска на YouTube: www.youtube.com/​watch?​v=MJNJjh4jORY
 +
 +Для предотвращения SQL/​HTML-инъекций необходимо осуществлять фильтрацию всего пользовательского ввода на предмет наличия недопустимых символов,​ но разработчики web-приложений люди ленивые и фильтрацию реализуют кое-как,​ спустя рукава,​ поэтому средства автоматической фильтрации,​ встроенные в платформу .NET, оказались большим подарком и завоевали всеобщую любовь и популярность. Между тем, качество автоматического фильтра оставляет желать лучшего и он содержит множество ошибок,​ затрагивающих в том числе и Microsoft .NET Framework 2.0, входящий в состав "​неуязвимой"​ Висты.
 +
 +{{exploits-review-0x0e_Image_8.png?​552}}
 +
 +Рисунок 9 официальный сайт комании ProCheckUp
 +
 +В частности,​ компания ProCheckUp (http://​procheckup.com) обнаружила весьма "​солидный"​ баг в системе управления контентом (.NET Content Management System или, сокращенно,​ .NET CMS), допускающим подстановку .NET-скриптов в поле '​lang'​ стандартного приложения '​logon.aspx',​ выполняемом в контексте уязвимого WEB-сайта,​ что позволяет реализовать атаку типа Cross Site Scripting путем отправки следущего GET-запроса:​
 +
 +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
 +
 +Листинг 6 GET-запрос к logon.aspx, подставляющий .NET-скрипт в поле lang
 +
 +