ТЕХНИКА СЕТЕВЫХ АТАК - Крис Касперский

Универсального выхода из этой ситуации не существует, но посредственных решений проблемы можно предложить сколько угодно. Чаще всего эмуляторы при открытии файла в текстовом режиме самостоятельно обрабатывают символы перевода строки, следуя UNIX-соглашению. Файл, открытый в двоичном режиме читается «как есть», поскольку невозможно различить действительный перевод строки от совпадения последовательности символов. К сожалению, многие приложения обрабатывают текстовые файлы, открывая их в бинарном режиме. Поэтому, лучше всего переносить файлы данных вручную, при необходимости заменяя символы переноса строки.

Точно так, в MS-DOS и UNIX не совпадают наименования устройств. Например, для подавления вывода сообщений на экран в MS-DOS используется конструкция “»nul” (“echo Это сообщение никогда не появится на экране»nul”), а в UNIX - “»/dev/null” (“echo Это сообщение никогда не появится на экране» /dev/null”). Другие примеры различий показаны в таблице 1

– Устройство Название в UNIX Название в MS-DOS

– Консоль /dev/tty Con

– Стандартный ввод /dev/stdin Con

– Стандартный вывод /dev/stdout Con

– Черная дыра /dev/null Nul

– Привод гибких дисков /dev/fd А: (B:)

– Параллельный порт /dev/lp Com

– Последовательный порт /dev/mod lpt

Таблица 1 Различия наименования устройств в UNIX и MS-DOS

Поэтому, любой эмулятор должен предоставлять собственную библиотеку функций для работы с файлами, имитирующую наличие указанных устройств. Это реализуется простым преобразованием имен и контролем доступа операций записи и чтения (например, в стандартный ввод нельзя записывать, хотя MS-DOS это позволяет, совмещая и ввод, и вывод в одном устройстве под названием ‘con’ - сокращение от console).

К сожалению, существуют и такие различия, сгладить которые невероятно трудно. Так, например, система UNIX чувствительна к регистру в именах файлов и допускает мирное сосуществование “myfile” и “MyFile” в одном каталоге. Кажется, единственный способ приучить к этому Windows, - реализовать собственную файловую систему, но существуют более простые, хотя и менее элегантные решения. Некоторые эмуляторы ассоциируют файлы с таблицами виртуальных имен, обрабатываемых по правилам UNIX. (Смотри рисунок 005.txt)

Создание эмулятором таблицы виртуальных имен, чувствительных к регистру

Намного хуже дело обстоит с поддержкой сырых гнезд (SOCK_RAW). Если говорить просто, сырые гнезда позволяют прикладной программе самостоятельно сформировать заголовок IP пакета, - действие редко используемое в нормальной жизни, но необходимое для множества атак.

Спецификация WINSOCK 2.x как будто бы подтверждает их наличие в Windows, но на самом деле, соответствующие функции реализованы неправильно и посылают подложный пакет, помещая пользовательский заголовок в область данных. Не то чтобы ситуация была полностью безнадежна, но написание собственных драйверов TCP/IP требует надлежащей квалификации разработчиков, и ни один из известных автору эмуляторов сырых гнезд не поддерживает.

К слову сказать, помимо гнезд семейства AF_INET, в UNIX существуют и гнезда используемые для межпроцессорного взаимодействия, не поддерживаемые WINSOCK, но реализуемые подавляющим большинством эмуляторов.

Рассмотрев теоретические различия между UNIX и Windows, перейдем к сравнению конкретных реализаций эмуляторов. Для этого возьмем двух ярких представителей, UWIN от компании AT amp;T (кто знает UNIX лучше AT amp;T?) и CYGWIN, поддерживаемый в рамках проекта GNU [83].

Логотип эмулятора UWIN

Для некоммерческого использования полноценную копию UWIN можно получить бесплатно, посетив сайт автора - http://www.research.att.com/sw/tools/uwin/. Установленный UWIN предоставляет следующие возможности: “UWIN has a set of popular shells like ksh (Kornshell) amp; tcsh (C shell) and more than 300 utilities like vi, ls, ps, grep, tail, uudecode/uuendecode, mailx, find, perl, awk, etc along with a vt100 terminal emulation. It also provides a Telnet server along with other inet daemons and utilities like telnet, ftp, rsh, rlogin, and their corresponding servers for Windows NT, enabling a user to remotely access the system over the network. Optional tools include the Apache Web-server and bind DNS server. [84]”

Врезка «Системные требования UWIN»*

· Software requirements Software requirements

· UWIN Base toolkit + UWIN SDK

· Microsoft Visual C/C++ 4.0 or higher or GNU C/C++ compiler

· Microsoft Windows NT 4.0 or higher (Workstation or Server) or

· Microsoft Windows 95/98

· Hardware requirements Hardware requirements

· Intel x86, Pentium, Pentium Pro and compatible systems

· 30-100MB of available hard-disk space

UWIN содержит множество популярных командных оболочек, свыше 300 необходимых для работы утилит и даже позволяет запускать Apache WEB сервер и DNS сервер. Администраторов Windows NT не может не порадовать наличие полноценного telnetd -демона (как известно в штатную поставку Windows NT не входит никаких средств удаленного управления компьютером) [85].

Рисунок 048 Демонстрация наличия telnet-сервера в эмуляторе UWIN

Разработчикам пригодится компилятор GNU C/C++ и отладчик gdb, или любой другой инструментарий - по выбору. Например, perl, awk, tcl… да всего не перечислишь! Кстати, в UWIN входит «обертка» (wrapper) для Microsoft Visual C++, дополняющая его возможностью обработки исходных текстов UNIX-приложений. Разумеется, откомпилированный текст можно отлаживать чем угодно, в том числе и Soft-Ice, не имеющим аналогов в среде UNIX.

Наконец, даже никого не собирающиеся атаковать пользователи, со временем обнаружат - пользоваться командными оболочками UNIX, намного удобнее, чем елозить мышью. Благо, UWIN позволяет запускать не только UNIX, но и Windows-приложения, умело обращаясь не только с дисками, но и с реестром.

Отныне ветви реестра будут представлены каталогами, а ключи - файлами. Корневой раздел реестра монтируется в каталог “/reg” На рисунке 049 показано, как вывести на экран содержимое ветви реестра “HKEY_CURRENT_USERNetworkPersistentH”. Но этим возможности UWIN не ограничиваются. В реестре становится возможным хранить и обрабатывать файлы, точь-в-точь как на обычном жестком диске!

 Эмулятор UWIN позволяет обращаться с реестром Windows точно так, как с файлом

Выше был употреблен термин “монтируется” - UWIN эмулирует монтируемую файловую систему, то есть позволяет произвольным образом объединять в одну логическую структуру, файлы и каталоги физически расположенные на разных дисках и даже компьютерах. По умолчанию корневым каталогом назначается директория, в которую инсталлирован UWIN. Корень диска «С» становится каталогом “/C/”, и соответственно “/A/”, “/B/”, “/D/”, “/E” для остальных дисков (если они есть). Каталог Windows доступен как “/C/Windows”, так и через короткий псевдоним “/Win”. Сетевые компьютеры автоматически монтируются так же, как и в Windows, но с наклоном черты в обратную сторону, т.е. “\SERVERC” станет называться “//SERVER/C”. Вообще же узнать, как смонтирован тот или иной ресурс можно с помощью команды mount. Например, на компьютере автора результат ее работы выглядел так:

· C:Program FilesUWIN on / type FAT32 (ic,text,grpid,suid,rw)

· C:Program FilesMicrosoft Visual Studiovc98 on /msdev type FAT32 (ic,text,grpid,suid,rw)

· A: on /A type FAT (ic,text,grpid,suid,rw)

· C: on /C type FAT32 (ic,text,grpid,suid,rw)

· D: on /D type FAT32 (ic,text,grpid,suid,rw)

· E: on /E type FAT32 (ic,text,grpid,suid,rw)

· F: on /F type FAT32 (ic,text,grpid,suid,rw)

· //SERVER/C on /H type FAT ()

· /usr/bin on /bin type LOFS (ic,text,grpid,suid,rw)

· /usr/lib on /lib type LOFS (ic,text,grpid,suid,rw)

· /usr/etc on /etc type LOFS (ic,text,grpid,suid,rw)

· /usr/dev on /dev type LOFS (ic,text,grpid,suid,rw)

· /C/WINDOWS on /win type FAT32 (ic,text,grpid,suid,rw)

· /C/WINDOWS/SYSTEM on /sys type FAT32 (ic,text,grpid,suid,rw)

· /usr/proc on /proc type PROC (ic,text,grpid,suid,rw)

· /usr/reg on /reg type REG (ic,text,grpid,suid,noexec,rw)

Однако, монтируемая файловая система видна только из-под UWIN, а Windows-приложения даже и не подозревают о ней. Поэтому, попытка вызвать notepad для просмотра фала /win/readme.txt провалится, а правильный вариант должен выглядеть так: “/win/notepad C:\windows\readme.txt”. Дублирование косой черты обязательно, в противном случае Windows сообщит: “Не удается найти файл C:windowsreadme.txt” (такая ситуация показана на рисунке 050):

Рисунок 050 Демонстрация вызова приложений Windows из эмулятора UNIX

Так происходит потому, что в UNIX (и UWIN), косая черта “” зарезервирована за управляющими символами (например, “t” обозначает знак табуляции, а “n” - перенос строки), а когда требуется отобразить сам символ обратной черты, прибегают к его дублированию.

Каталог “/dev” предназначен для управления устройствами. Его содержимое может быть следующим:

· $ ls /dev

· clipboard ptyp0 ptyq7 tty06 tty29 ttypb

· fd ptyp1 ptyq8 tty07 tty30 ttypc

· fd0 ptyp2 ptyq9 tty08 tty31 ttypd

· fd1 ptyp3 ptyqa tty09 tty32 ttype

· lp ptyp4 ptyqb tty10 tty33 ttypf

· lp0 ptyp5 ptyqc tty11 tty34 ttyq0

· lp1 ptyp6 ptyqd tty12 tty35 ttyq1

· lp2 ptyp7 ptyqe tty13 tty36 ttyq2

· mod0 ptyp8 ptyqf tty14 tty37 ttyq3

· mod1 ptyp9 rmt0 tty15 tty38 ttyq4

· mod2 ptypa rmt0n tty16 tty39 ttyq5

· mod3 ptypb rmt1 tty17 tty40 ttyq6

· mod4 ptypc rmt1n tty18 ttyp0 ttyq7

· mod5 ptypd stderr tty19 ttyp1 ttyq8

· mod6 ptype stdin tty20 ttyp2 ttyq9

· mod7 ptypf stdout tty21 ttyp3 ttyqa

· mt0 ptyq0 tty tty22 ttyp4 ttyqb

· mt0n ptyq1 tty00 tty23 ttyp5 ttyqc

· mt1 ptyq2 tty01 tty24 ttyp6 ttyqd

· mt1n ptyq3 tty02 tty25 ttyp7 ttyqe

· null ptyq4 tty03 tty26 ttyp8 ttyqf