На главную | Содержание | Назад | Вперёд
Наши друзья

 

 

Поиск точек входа

Существует несколько средств, с помощью которых можно обнаружить файлы и другие точки входа. В случае Windows NT список наиболее популярных средств для просмотра реестра или файловой системы можно найти по адресу http://www. sysinternals . com. Средства под названиями filemon и regmon хорошо подхо­дят для выявления файлов и параметров реестра. Это достаточно известные средст­ва. Другие программы, предоставляющие подобные сведения, называют диспетче­рами API (API monitor). На 1 показано окно популярной программы File Monitor. Программы-диспетчеры подключаются к определенным вызовам API и по­зволяют определить, какие параметры передаются этим вызовам. Иногда эти про­граммы позволяют в оперативном режиме изменять вызовы функций — простейшая форма внесения ошибок.
Для изменения вызовов функций API можно воспользоваться программой Fai­lure Simulation Tool (FST) от компании Cigital (2). Программа FST внедряется между приложением и DLL с помощью перезаписи таблицы адресов прерываний. Благодаря этому диспетчер API видит, какие функции API вызываются и какие па­

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

конфигурационного файла в нескольких областях. Если хакеру доступна область, где может быть обнаружен конфигурационный файл, это предоставляет возмож­ность для атаки.
Шаблон атаки: использование сведений о возможных путях поиска конфигурационного файла
Если разместить копию конфигурационного файла в ранее пустой каталог, атакуемая про­грамма может найти версию хакера первой и прекратить все дальнейшие поиски. В боль­шинстве программ уделяется недостаточно внимания безопасности, т.е. не выполняется ни­каких проверок относительно владельца файла. Переменная окружения PATH в среде UNIX часто определяет, что программа должна выполнять поиск данного файла в различных катало­гах. Проверьте эти каталоги на предмет возможной установки "троянского" файла.
Трассировка входных данных
Трассировка входных данных — это чрезвычайно полезный, но крайне утоми­тельный способ отслеживания информации, касающейся пользовательских входных данных. К процессу трассировки относится установка точек останова, когда пользо­вательские данные попадают в программу, и трассировка внутри программы. Для экономии времени хакер может воспользоваться средствами трассировки, средства­ми управления потоком и точками останова в памяти. Эти методы атаки более под­робно описаны в главе 3, "Восстановление исходного кода и структуры программы". В следующем примере будут продемонстрированы хитрости отслеживания пути, чрезвычайно полезные при сборе информации о пользовательских входных данных.
Использование GDB и IDA-Pro по отношению к двоичному файлу SOLARIS/Sparc-программы
Хотя IDA-Pro является Windows-программой, ее профессиональная версия мо­жет использоваться для декомпиляции двоичных файлов, скомпилированных на различных платформах. В нашем примере мы воспользовались IDA-Pro для деком-пиляции одного из главных исполняемых файлов сервера Netscape I-Planet Applica­tion Server, запущенного на платформе Solaris 8/Ultra-SPARC 10.
Программа GDB, вероятно, является одним из самых мощных отладчиков. К до­полнительным возможностям GDB можно отнести функцию установки точек оста­нова по условию и возможность использования выражений. Программа GDB, безус­ловно, также позволяет дизассемблировать программный код, поэтому технически можно обойтись и без IDA. Однако IDA наиболее удобна при выполнении крупного проекта по дизассемблированию.
Расстановка точек останова и использование выражений
При восстановлении исходного кода точки останова играют огромную роль. Точ­ка останова позволяет нам остановить выполнение программы в определенном мес­те. После остановки можно исследовать содержимое памяти, а затем пошагово ис­следовать вызовы функций. Если запустить процесс дизассемблирования в одном

окне, можно вывести результат следующего действия в другое окно и сделать нуж­ные заметки. Дизассемблер IDA особенно удобен тем, что позволяет сделать записи в ходе процесса дизассемблирования. Одновременное использование дизассемблера, что приводит к созданию дизассемблированного кода (так называемый dead listing), а также отладчика, является одним из вариантов исследования по методу "серого ящика".
При установке точек останова можно работать в двух направлениях: "изнутри наружу" или "снаружи внутрь". При первом методе выполняется поиск интересую­щего системного вызова или функции API, например, по операции с файлом. Затем устанавливается точка останова на вызов этой функции и начинается обратное ис­следование: не использовались ли в вызове пользовательские данные? Это мощный способ для восстановления исходного кода программы, но он должен быть макси­мально автоматизирован. При работе по методу "снаружи внутрь" сначала опреде­ляется функция, в которой пользовательские данные впервые обрабатываются про­граммой, и затем начинается пошаговое исследование и анализ исполнения кода в программе. Это очень удобно при определении участка кода, где условные переходы выполняются на основе пользовательских данных. Оба метода могут быть объеди­нены в целях достижения максимального эффекта.
Поиск адресов памяти для выполняемой программы, полученных с помощью IDA
К сожалению, адреса памяти, которые отображаются в окне IDA, полностью не соответствуют адресам, используемым выполняемой программой при одновремен­ной работе программы GDB. Однако определить смещения не столь сложно даже вручную. Например, если IDA показывает, что вызов функции INTutil_uri_is _evil_internal хранится по адресу 0x00056140, то следующие команды позво­ляют обнаружить действительный адрес во время исполнения. В окне IDA отображается следующая информация.
Jnl:llli(lll    !     MMIIIIIIMMI SUBROUTINE I I I I I I II I I I I I I II I I I I I I I I I I i I I I I I I I I I I I I
.text:00056140 .text:00056140
.text: 00056140 .global   INTutil_uri_is_evil_internal
Установка точки останова с помощью GDB позволяет узнать действительную страницу памяти для этой подпрограммы, как показано ниже.
(gdb)   break *INTutil_uri_is_evil_internal Breakpoint  1 at 0xffld6140
Теперь мы знаем, что адрес 0x00056140 соответствует адресу 0xffld6140. Об­ратите внимание, что смещение 0x614 0 на странице памяти одинаково для обоих адресов. При грубом приближении заменяются только два старшие байта адреса.

 

На главную | Содержание | Назад | Вперёд
 
Яндекс.Метрика