Защита от хакеров корпоративных сетей. Глава 4. Методология ( Коллектив авторов, 2005)

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

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

Примечание

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

Выбор субъективен и целиком определяется предпочтениями исследователя. Уже говорилось о широком распространении программных средств определения уязвимостей и аудита программного обеспечения. Некоторые из них по своим возможностям аналогичны Web CGI или SQL Database. Другие, как, например, Bugzilla, предоставляют ряд дополнительных возможностей, включая прекрасный интерфейс, ведение учетных записей пользователя, идентификаторов ошибок и их отслеживание.

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

Анализ исходного текста программы

Анализ исходного текста программы предполагает экспертизу текста программы на предмет ошибок. Программа может быть написана на языках C, Perl, Java, C++, ASP, PHP и им подобных. Обычно аудит исходного текста программы начинается с поиска потенциально небезопасных функций, или, другими словами, функций, подверженных ошибкам.

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

Следует обратить внимание на использование функций языка C strcpy и sprintf. Злоумышленник часто их применяет, пытаясь добиться переполнения буфера из-за отсутствия или неверного выполнения проверки принадлежности адресов диапазону правильных адресов памяти. Использование других функций, как, например, mktemp, может привести к перезаписи файлов в результате конкуренции программ, содержащих функцию, или к повышению привилегий.

Один из методов анализа исходного теста программы – построчная экспертиза программы в соответствии с алгоритмом ее выполнения. Это более тщательное изучение программы, на которое уходит больше времени.

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

Анализ различий – метод определения уязвимостей программы, который применяется, если производитель сообщил об уязвимости, не детализируя ее сути. С помощью этого метода определяется, был ли изменен файл программы, a если был, то где именно.

diff – одна из лучших утилит, реализующая рассматриваемый метод. Она поставляется с большинством версий операционных систем UNIX и благодаря Фонду свободно распространяемого программого обеспечения (Free Software Foundation) реализована на многих платформах. diff сравнивает две копии данных и отображает любые различия между ними, то есть она позволяет найти различия в двух исходных файлах программ и их местонахождение.

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

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

Видно, что в первой версии программы axspawn.c используется функция sprintf без всяких ограничений на длину выводимой строки данных, а во второй – введено ограничение на длину выводимой строки в спецификации преобразования.

В некоторых случаях производитель может выпустить патч, который будет сообщать отличия между двумя версиями программы. Обычно такие патчи выпускаются для операционных систем типа BSD (BSD – Berkeley Software Design Incorporated – компания-разработчик программного обеспечения), например FreeBSD. В январе 2002 года была найдена уязвимость в пакете инструментальных средств операционной системы FreeBSD. До ее устранения пользователь мог извлечь данные во временную директорию и изменить их. До тех пор, пока уязвимость не была всесторонне изучена, патч pkg_add сообщал точное местонахождение уязвимости:

Удаляемая патчем часть исходного текста обозначена знаком минус (-), а добавляемая – знаком плюс (+). Можно увидеть, что часть исходного текста, содержащая код создания директории с разрешениями 0755, заменяется на код, создающий директорию с разрешениями 0700.

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

Анализ двоичного кода

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

Один из методов определения потенциальных уязвимостей заключается в трассировке выполнения программы. Для трассировки используется различный инструментарий. Для этой цели в системе Solaris применяется специальный пакет программ truss компании Sun. В других операционных системах используются аналогичные программы, например strace для Linux.

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

Использование трассировки позволяет определить, где и когда проявится уязвимость в исследуемой программе.

Применение отладчиков – еще один способ поиска уязвимостей. Отладчики позволяют выявить ошибки программы во время ее выполнения. На практике применяются различные отладчики. Gnu Debugger (GDB) – один из наиболее известных среди них.

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

Другой способ аудита двоичного кода заключается в анализе принятых соглашений и документов по разработке программ (которые не следует путать с исходным кодом программ). Материалы по разработке программ обычно представляются в виде диаграмм, информационных листов или спецификаций, как, например, RFC (Requests for Comments – запросы на комментарии, серия документов IETF, первые упоминания о которой относятся к 1969 году. Документы этой серии содержат описания протоколов Internet и связанную с ними информацию).

Анализ программ на основе протокола спецификации может привести к различным выводам. Этот тип исследования заключается не только в установлении соответствия анализируемой программы спецификациям проектирования, но и в детальном анализе проблемных ситуаций в ней. Воспользовавшись результатами исследования основополагающих принципов построения протокола, например Telnet или POP3, можно протестировать службу, написанную на основе выбранного протокола, на предмет ее соответствия протоколу. Рассматривая ранее изученные классы атак на выбранные части реализации протокола (атаки, нацеленные на переполнение буфера или ошибки форматирующей строки), можно написать программу, демонстрирующую найденную уязвимость.

Последний, заслуживающий внимания метод поиска уязвимостей – это применение анализаторов. Анализаторы – это инструмент исследования уязвимостей, который применяется как средство поиска неисправностей или для отладки. Другими словами, анализаторы – это модули проверки текущего состояния программы. К сожалению, цели применения анализаторов могут быть разными.

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

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

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

Поиск функций, подверженных ошибкам

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

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

Переполнение буфера, известное также как ошибка граничных условий, происходит в том случае, когда размер записываемых в память данных превышает размер выделенной для этого области памяти. Елиас Леви (Elias Levy), известный как Alephl, написал на эту тему статью «Smashing the Stack for Fun and Profit» («Разрушение стека для забавы и обогащения»). Со статьей можно ознакомиться в 49-ом выпуске Phrack, статья номер 14.

Посмотрите на следующую программу:

В этой написанной на языке C программе приведен пример использования функции strcpy. Данные из массива argv [1], в котором хранится аргумент вызова программы, копируются функцией strcpy в массив символов, для которого при объявлении была выделена память для восьми символов. Поскольку в программе не выполняется никаких проверок размера пересылаемых данных, то при копировании более восьми символов происходит переполнение буфера.

Функция sprintf — еще один пример часто встречающейся подверженной ошибкам функции. В результате ее применения возможно переполнение буфера, как это показано в следующем примере:

Как и в предыдущем примере, строка символов аргумента программы копируется в восьмибайтовый массив символов. Поскольку при копировании из argv [1] не выполняется никаких проверок на соответствие размера пересылаемых данных размеру памяти, в которую выполняется копирование, то в результате возможно переполнение буфера.

Применение функции strcat без проверки размера обрабатываемых данных также может привести к переполнению буфера, как это видно из следующего примера:

Данные командной строки из массива argv [1] передаются функции overflow_function, которая сцепляет их с данными восьмибайтового массива символов с. Поскольку в программе размер сцепляемых данных не проверяется, то в результате возможен выход за границы массива c.

Gets – еще одна проблематичная функция языка C. Компилятор GNU языка C выдает предупреждающее сообщение при компиляции программ с функцией gets, потому что эта функция никак не контролирует размер получаемых данных. Посмотрите на следующий пример:

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

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

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

Ошибки проверки входных данных программы могут привести к уязвимостям форматирующей строки. Уязвимость форматирующей строки проявляется при использовании в программе таких спецификаций преобразования, как, например, %i%i%i%i или %n%n%n%, что может привести к неожиданному результату. Подробно форматирующие строки рассмотрены в главе 9.

Но перед этим приведем пример программы с уязвимой форматирующей строкой. Проанализируйте следующую программу:

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

Проверка программами Web-интерфейса, например CGI-программами, входных данных программы часто приводит к неожиданным результатам. Нередко недостаточно квалифицированно написанные CGI-программы (особенно это касается программ, написанных на языке Perl) позволяют выполнять команды, заключенные в специальные символы, что дает возможность выполнять произвольные команды системы с привилегиями Web-пользователя. В некоторых случаях это может привести к серьезным последствиям. Например, к удалению файла index.html, если HTTP-процесс является владельцем этого файла и имеет право писать в него данные. Или к предоставлению пользователю локального доступа к системе с разрешениями HTTP-процесса, если пользователь свяжет оболочку shell c произвольным портом системы.

К сходным проблемам может привести предоставленная пользователю возможность выполнять произвольные SQL-команды. Обычно CGI-программы используются для облегчения взаимодействия между внешним Web-интерфейсом и серверной частью системы управления базами данных, поддерживающих SQL, например Oracle, MySQL или Microsoft SQL Server. Пользователь, который может выполнять произвольные SQL-команды, сможет просматривать произвольные таблицы, обрабатывать данные таблиц и даже удалять их.

Посмотрите на вариант вызова функции open:

Эта функция не проверяет входные данные, переданные программе в $argv [0]. Добавив к входным данным символы точек (..), становится возможным сменить директорию и просмотреть родительский каталог, в котором может храниться важная информация. Более подробное обсуждение ошибок проверки входных данных приведено в главе 7.

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

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

В некоторых операционных системах эта программа создает файл во временной директории с предопределенным именем, состоящим из строки символов, в которую входят слово example, пять символов идентификатора процесса и одна буква латинского алфавита. Первый недостаток рассматриваемой программы заключается в том, что между проверкой существования файла и его созданием может возникнуть ошибка «состояние гонок» (Race Conditions), обусловленная соперничеством программ за ресурсы. Второй – в том, что имя файла можно сравнительно легко предсказать, поскольку идентификатор процесса можно определить, а последний символ – это одна из 26 букв английского алфавита. В результате возможна успешная для злоумышленника атака символических связей. Для того чтобы определить, позволяет ли операционная система воспользоваться указанными уязвимостями, достаточно исследовать файлы, созданные программой в директории /tmp.

При помощи такой утилиты, как grep, можно исследовать большие программные файлы на наличие в них известных ошибок. Означает ли это, что будут выявлены все уязвимости? К сожалению, нет, но это позволит найти и устранить большинство часто встречающихся ошибок. Единственно надежный способ обеспечения безопасности программного обеспечения – построчный аудит многочисленными независимыми экспертами. И даже после этого уровень безопасности программного обеспечения может быть оценен только как достаточно высокий, без гарантий полной безопасности.

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

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

В составе операционных систем Windows подобный инструментарий не поставляется, поэтому используют программные средства других производителей. До настоящего времени главным их источником для Windows был сайт SysInternals по адресу www.sysinternals.com в Интернете. Особенно интересны программы FileMon, RegMon, а в случае NT – HandleEx. Подробнее о них будет рассказано в главе 5. Все, что вам необходимо знать об этих средствах сейчас, – это то, что они позволяют контролировать выполняющуюся программу (или программы), узнать, к каким файлам обращается контролируемая исследователем программа, читает ли она их или пишет в них информацию и куда именно, какие другие файлы она ищет. Перечисленные функции реализованы в программе FileMon. Программа RegMon позволяет исследовать то же самое применительно к реестру Windows NT: к каким ключам реестра программа обращается, какие ключи читает, обновляет, ищет и т. д. HandleEx реализует те же самые функции, но несколько другим способом. Результаты ее работы упорядочены по процессам, дескрипторам файлов и тем объектам, на которые указывают дескрипторы файлов.

В качестве дополнительной услуги доступны свободно распространяемые версии почти всех инструментальных средств SysInternals, причем большинство из них с исходными текстами программ. (Помимо сайта SysInternals, на родственном сайте Winternals.com продаются аналогичные коммерческие инструментальные средства с несколько большими возможностями.) Для пользователя UNIX в этом нет ничего необычного, но для пользователя Windows это приятная неожиданность.

В состав большинства дистрибутивов UNIX включены программные средства, которые могут облегчить анализ VB-программ. В списке Rosetta Stone перечислено много программ трассировки. Список можно найти по адресу http://bhami.com/rosetta.html в Интернете. Любая программа трассировки реализует низкоуровневые функции, поэтому она может работать только под управлением ограниченного количества операционных систем. Примерами программ трассировки могут служить программы trace, strace, ktrace и truss, а также утилита strace, выполняемая в операционной системе Red Hat Linux, версия 6.2. Утилита (как и большинство ранее упомянутых программ трассировки) позволяет исследовать системные обращения (обращения к ядру операционной системы) и их параметры, что позволяет многое узнать о работе программы.

Приоткрывая завесу

Декомпиляторы VB

Изрядное количество программ во всем мире написано на Visual Basic (VB). Сюда относятся как зловредные программы, так и программы законопослушных программистов. VB бросает вызов всякому, кто отважится декомпилировать программу, написанную на этом языке. Последний свободно доступный декомпилятор мог работать только с программами VB3. Начиная с VB5, результат компиляции программы может быть представлен как во внутреннем коде исполняемого модуля («native code»), реализующем стандартное обращение к Windows, так и в p-code. P-код – это псевдокод, который похож на байт-код (или машинно-независимый код), генерируемый Java-компилятором. P-код распознает интерпретатор реального времени Visual Basic VBRUN300.DLL, VBRUN500.DLL или VBRUN600.DLL. Сложность заключается в том, что очень мало доступной документации, в которой описано соответствие конструкций исходного текста программы функциям VB в откомпилированной программе. Конечно, всегда можно декомпилировать интерпретатор VB DLL и восстановить соответствие, но это очень трудоемкое занятие.

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

Для удобства восприятия протокол трассировки дополнен комментариями:

Утилита strace не начинает вывод до тех пор, пока не будет вызвана команда cat. Поэтому нельзя отследить процесс ее поиска командным процессором shell. К моменту начала работы утилиты strace команда cat находилась в директории /bin. Из примера трассировки видно, что входными параметрами программы execve являются местонахождение cat, ее имя, аргумент (test) и список из 21 переменной окружения.

После вызова execve начинается обычный процесс загрузки: распределение памяти и т. д. Отметим свидетельствующий об ошибке код возврата, равный —1, при попытке открыть /etc/ld.so.preload. Ошибка поясняется диагностическим сообщением об отсутствии файла или директории. Действительно, такого файла нет. Из примера ясно, что если вместо файла указать параметры так, как это указано в примере open, execve самостоятельно найдет файл. Это было бы полезно для последующих действий привилегированного пользователя. Но для этого нужно поместить новый файл в директорию /etc, в которой запрещено что-либо делать до тех пор, пока кто-нибудь не откорректирует файл системных разрешений. В большинстве Unix-систем право записи в директорию /etc имеет только пользователь, получивший привилегированные права «root» тем или иным способом. Это еще одна причина, по которой обычные пользователи не могут писать в /etc. Если задаться целью спрятать Троянского коня, то лучшего места не найти (после того как будут получены права привилегированного пользователя root).

Прочитаны первые 4 Кб библиотеки libc. Libc – это стандартная библиотека коллективного доступа, в которой расположены функции, вызываемые из программ на языке C (такие как printf, scanf и т. д.).

Если в программе встречается вызов функции setlocale, то libc читает локализованную информацию (информацию о местной специфике) для определения формата отображения чисел, даты, времени и т. д. Напомним, что хотя стандартные разрешения не позволяют модифицировать файлы локализации непривилегированным пользователям, но их достаточно для чтения этих файлов. Добавим, что разрешения файлов обычно печатаются при выводе информации о каждом вызове fstat (например, в приведенном примере 0644). Это позволяет легко визуально отследить неверные разрешения. Если ищется файл локализации, в который предполагается записать информацию, будьте осторожны, чтобы при записи не получить ошибки переполнения буфера. Третий (косвенный) параметр в списке входных параметров – файлы локализации.

Наконец, команда cat открывает наш файл «test». Конечно, имя файла – это входные данные команды, но они безопасны для работоспособности команды из-за ее логики работы. В других случаях может потребоваться учет содержимого входного файла.

В заключение cat пытается прочитать 512 байтов из файла (читает 6) и выводит их на экран (который описан STDOUT с дескриптором файла 1). При повторной попытке прочитать очередные 512 байтов файла читается 0 байт, что свидетельствует о достижении конца файла. В результате файл закрывается, дескриптор файла освобождается и выполняется нормальный выход (признаком нормального выхода является нулевой код завершения).

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

Для сравнения приведем результат выполнения утилиты truss для той же самой команды, выполненной в системе Solaris 7 на машине (x86):

Проанализировав конец протокола, можно заметить, что в Solaris команда cat выполняется несколько по-другому. Различие проявляется в том, что в Solaris ош использует проецируемый в память файл для передачи диапазона адресов непосредственно вызову функции write. Эксперимент с большим файлом (результаты которого здесь не приведены) выявил цикл запросов между вызовами функций memorymap/write, причем за один раз обрабатывается 256 Кб.

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

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

Дизассемблеры, декомпиляторы и отладчики

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

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

Проблема несколько упрощается, если исследователь в состоянии разобраться с ассемблерным кодом, генерируемым декомпилятором. В этом случае декомпилятор особенно полезен. Рассмотрим пример результатов работы декомпилятора.

Среди коммерческих декомпиляторов для Windows хорошая репутация у IDA Pro компании DataRescue (пример работы декомпилятора показан на рис. 4.1). IDA Pro может декомпилировать программный код многих процессоров, включая виртуальную машину Java.

Рис. 4.1. Пример работы IDA Pro

На рисунке показан пример применения декомпилятора IDA Pro для дизассемблирования программы pbrush.exe (Paintbrush). IDA Pro нашел секцию внешних функций, используемых программой pbrush.exe. Если программа выполняется под управлением операционной системы, которая поддерживает разделяемые библиотеки (например, под управлением операционных систем Windows или UNIX), то она содержит список необходимых ей библиотек. Обычно этот список представлен в удобочитаемом виде, который легко обнаружить при экспертизе выполняемого кода. Для выполнения программ операционной системе также требуется этот список, поэтому она загружает его в память. В большинстве случаев это позволяет декомпилятору вставить список в двоичный код программы, сделав его более понятным.

Чаще всего таблица соответствия имен pbrush.exe недоступна, поэтому в большей части сгенерированного декомпилятором ассемблерного кода отсутствуют имена.

Оценочную версию IDA Pro, пригодную для первоначального знакомства с программой, можно загрузить с www.datarescue.com/idabase/ida.htm. SoftICE компании Numega – другой популярный отладчик. Дополнительные сведения о нем можно найти по адресу www.compuware.com/products/numega/drivercentral/.

Для сравнения была написана небольшая программа на языке C (классическая небольшая программа, выводящая строку «Hello World»). Для отладки использовался отладчик GNU (GDB). Код программы представлен ниже:

Программа была скомпилирована с включением отладочной информации (был включен переключатель —g):

Пример протокола отладки под управлением GDB показан ниже:

Была установлена точка прерывания при входе в функцию main. При ее достижении выполнение программы было приостановлено для выполнения программистом действий по отладке программы. Контрольная точка была установлена до выдачи команды run.

Команда run начинает выполнение программы под управлением отладчика.

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

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

После задания командой s («step») режима пошагового выполнения программы в отладчике выполняется переход к вызову функции printf. GDB сообщает о невозможности дальнейшей детализации функции printf из-за отсутствия в распоряжении отладчика исходного кода функции printf.

Далее выполняется несколько шагов реализации программы внутри функции printf и программа завершается. По команде c («continue») программа будет выполнена до следующей точки прерывания или будет завершена.

В число аналогичных программ входят программы nm и objdump пакета GNU. Программа objdump позволяет управлять объектными файлами. Она применяется для отображения символов объектного файла, его заголовка и даже дизассемблирования. Nm выполняет аналогичные действия, что и objdump, позволяя просматривать символьные ссылки на объектные файлы.

Инструментарий и ловушки

Инструментарий никогда не заменит знаний

Некоторые из средств дизассемблирования и отладки предлагают фантастические возможности. Но они, как и любой другой инструментарий, несовершенны. Особенно это проявляется при анализе злонамеренного кода (вирусов, червей, Троянских коней) или специально разработанных программ. Обычно авторы подобных поделок делают все возможное для затруднения их анализа и снижения эффекта от применения отладчиков, дизассемблеров и других подобных инструментальных средств. Например, вирус RST для Linux в случае обнаружения, что он работает под управлением отладчика, завершает свою работу. Этот же вирус при инфицировании исполняемых и компонуемых файлов ELF (Executable and Linkable Format – формат исполняемых и компонуемых модулей) модифицирует их заголовки таким образом, что некоторые дизассемблеры не могут дизассемблировать двоичный код вируса (обычно это достигается путем размещения кода вируса в необъявленном программном сегменте). Часто злоумышленный код шифруется или сжимается, что защищает его от экспертизы. Черви Code Red распространялись половинками своих программ, маскируясь под строки переполнения, и, таким образом, формат их двоичных данных не подходил ни под один из стандартных заголовков файла.

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

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

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

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

Тестирование методом «черного ящика» может быть сравнено с бинарным аудитом (binary auditing). Любой аудит так или иначе имеет дело с бинарными данными, предусматривающими одну возможность из двух. Известны различные толкования «черного ящика» в зависимости от знаний исследователя о его внутреннем строении (его прозрачности). В книге рассматриваются два типа ящиков: «черный ящик» и «ящик из обсидиана». Конечно, это мысленные, а не реальные физические объекты. Тип ящика отражает уровень знаний исследователя о происходящих в системе внутренних явлениях.

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

Чипы

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

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

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

Кроме того, следует попытаться сделать выводы, основываясь на других компонентах устройства. Можно составить список компонентов, подсоединенных к чипу, и выяснить, к каким контактам они подсоединены. Например, может оказаться, что два контакта в конечном счете подключены к светодиоду LED (LED – Light-Emitting Diode – светоизлучающий диод).

Если окажется, что чип – простое устройство TTL-логики (transistor-transistor logic – транзисторно-транзисторные логические схемы), то можно определить реализуемые этим чипом простые логические функции, подавая на различные контакты напряжение, эквивалентное сигналам «истина/ложь» и одновременно измеряя выходное напряжение на других контактах. Если удастся определить, что чип относится, например, к классу схем И-НЕ (NAND (not-and) gate), то по каталогу микросхем можно определить исследуемый чип или его аналог.

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

С образцами подобных устройств можно познакомиться по адресу www.parallaxinc.com/html_files/products/Basic_Stamps/module_bs2p.asp. Parallax производит семейство чипов со встроенным интерпретатором BASIC, отличающихся различными комбинациями входных и выходных интерфейсов. Главная сложность подобного устройства заключается в том, что число его состояний заведомо больше, чем можно перечислить. Даже крошечный компьютер с небольшим количеством памяти может сгенерировать бесконечно большое число неповторяющихся результатов. В качестве простого примера представьте себе компьютер на одном чипе, который складывает большие целые числа. Все, что он может сделать, – это выполнить простую программу добавления 1 к введенному числу и вывести результат. Вероятно, исследователь быстро определит, что на компьютере выполняется простая программа сложения чисел, но определить другие возможности компьютера практически невозможно. Иными словами, ничего нельзя сказать о том, является ли это устройство компьютером общего назначения или оно выполняет единственную функцию.

Сложно найти закономерность при исследовании систем методом «черного ящика». Но некоторые извлекают пользу из этого. Закономерности могут быть найдены случайно или в результате активных исследований. Прежде чем попытаться скрыть какую-либо закономерность, следует удостовериться в том, что число вариантов ее проявления достаточно велико. Конкретный пример приведен в статье по адресу www.casinoguru.com/features/0899/f_080399_tocatch.htm. В статье говорится o жуликоватом технике игорных автоматов, который заменил чип в некоторых автоматах. В результате каждый раз при вбрасывании определенной последовательности монет в автомат и дерганья за ручку автомат выплачивал джек-пот. Речь идет об основных приемах «зашивки» в программы «секретных» недокументированных сообщений!

Если из результатов исследования и доступной информации непонятно, что это за чип, то вскройте его! Вскрыть чип? Именно так. Исследователям защитного корпуса таких устройств, как смарт-карты (smart card – кредитная карточка с микропроцессором), известно много способов их изучения, включая выжигание корпуса чипа кислотой и исследование его структуры под микроскопом. Подробнее эти вопросы освещены в главе 14.

Итак, если исследователь с помощью метода «черного ящика» не может разобраться с устройством чипа, то он должен вскрыть его. Опыт посещения автором копий обсидиана (вулканического стекла) в Аризоне наглядно демонстрирует это. Если держать обсидиан на расстоянии вытянутой руки, то он выглядит как черный камень. Но при ярком свете обсидиан становится немного прозрачнее. Таким образом, он не вполне «черный ящик», а скорее в той или иной степени прозрачный «ящик из обсидиана». Другими словами, у исследователя всегда есть возможность получить информацию о решаемой задаче.