Хакинг. Хакинг__искусство_эксплоита_2_е_469663841. Книга дает полное представление о программировании, машин ной архитектуре, сетевых соединениях и хакерских приемах
 Скачать 2.5 Mb.
|
ны оба флага SYN и ACK. Чтобы завершить установление связи, кли- ент посылает пакет, в котором сброшен флаг SYN, но установлен флаг ACK. После этого у всех пакетов в соединении флаг ACK установлен, а флаг SYN сброшен. Только у первых двух пакетов в соединении уста- новлен флаг SYN, потому что эти пакеты используются для синхрони- зации порядковых номеров (рис. 4.6). Клиент Пакет ACK SYN сброшен, ACK установлен seq # = 324808531 ack # = 288666268 Сервер Пакет SYN SYN установлен, ACK сброшен seq # = 324808530 ack # = 0 Пакет SYN/A CK SYN установлен, ACK установлен seq # = 288666267 ack # = 324808531 Рис. 4.6. Открытие соединения Порядковые номера позволяют TCP восстанавливать порядок получае- мых пакетов, обнаруживать потерю пакетов и не допускать смешения пакетов из разных соединений. При инициировании соединения на каждом его конце генерируется начальный порядковый номер. Этот номер сообщается другой стороне в первых двух пакетах SYN процедуры открытия соединения. Затем при передаче каждого пакета порядковый номер увеличивается на ко- личество байт в секции данных пакета. Этот порядковый номер вклю- чается в TCP-заголовок пакета. Кроме того, каждый TCP-заголовок содержит номер подтверждения, равный порядковому номеру другой стороны, увеличенному на 1. TCP прекрасно действует там, где необходимы надежность и двуна- правленная связь. Однако эти функции оборачиваются дополнитель- ными расходами на связь. Для UDP характерен гораздо меньший объем накладных расходов и встроенных функций, чем для TCP. Ограниченная функциональ- ность делает его похожим на протокол IP: он не устанавливает соеди- нение и не надежен. Без встроенных функций для создания соедине- ний и обеспечения надежности UDP оказывается альтернативным про- токолом, предполагающим, что эти проблемы будет решать само при- ложение. Устанавливать соединение требуется не всегда, и в таких си- туациях UDP – более удачный выбор. UDP-заголовок, определенный в RFC 768, относительно невелик. Он состоит из четырех 16-разрядных 252 0x400Сетевое взаимодействие значений в таком порядке: порт отправителя, порт получателя, длина и контрольная сумма. 0x440 Анализ сетевых пакетов (сниффинг) На канальном уровне пролегает различие между коммутируемыми и некоммутируемыми сетями. В некоммутируемой сети (unswitched network) пакеты Ethernet проходят через каждое имеющееся в сети устройство в предположении, что любое устройство будет рассматри- вать только адресованные ему пакеты. Однако довольно легко задать для устройства неразборчивый режим (promiscuous mode), в котором оно будет принимать все пакеты независимо от их адресата. Большин- ство программ перехвата пакетов, таких как tcpdump, по умолчанию переводят прослушиваемое ими устройство в неразборчивый режим. Неразборчивый режим можно установить с помощью команды ifcon- fig , как показывает следующий листинг. reader@hacking:/booksrc $ ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:0C:29:34:61:65 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:17115 errors:0 dropped:0 overruns:0 frame:0 TX packets:1927 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4602913 (4.3 MiB) TX bytes:434449 (424.2 KiB) Interrupt:16 Base address:0x2024 reader@hacking:/booksrc $ sudo ifconfig eth0 promisc reader@hacking:/booksrc $ ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:0C:29:34:61:65 UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:17181 errors:0 dropped:0 overruns:0 frame:0 TX packets:1927 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4668475 (4.4 MiB) TX bytes:434449 (424.2 KiB) Interrupt:16 Base address:0x2024 reader@hacking:/booksrc $ Перехват пакетов, которые могут быть не предназначены для всеобще- го обозрения, называют сниффингом (от sniff – нюхать). Сниффинг па- кетов, проходящих в некоммутируемой сети, в неразборчивом режиме может дать разнообразную полезную информацию, как показано в сле- дующем листинге. reader@hacking:/booksrc $ sudo tcpdump -l -X ‘ip host 192.168.0.118’ tcpdump: listening on eth0 21:27:44.684964 192.168.0.118.ftp > 192.168.0.193.32778: P 1:42(41) ack 1 win 17316 0x0000 4500 005d e065 4000 8006 97ad c0a8 0076 E..].e@........v 0x0010 c0a8 00c1 0015 800a 292e 8a73 5ed4 9ce8 ........)..s^... 0x0020 8018 43a4 a12f 0000 0101 080a 0007 1f78 ..C../.........x 0x440 Анализ сетевых пакетов (сниффинг) 253 0x0030 000e 0a8a 3232 3020 5459 5053 6f66 7420 ....220.TYPSoft. 0x0040 4654 5020 5365 7276 6572 2030 2e39 392e FTP.Server.0.99. 0x0050 3133 13 21:27:44.685132 192.168.0.193.32778 > 192.168.0.118.ftp: . ack 42 win 5840 0x0000 4510 0034 966f 4000 4006 21bd c0a8 00c1 E..4.o@.@.!..... 0x0010 c0a8 0076 800a 0015 5ed4 9ce8 292e 8a9c ...v....^...)... 0x0020 8010 16d0 81db 0000 0101 080a 000e 0c56 ...............V 0x0030 0007 1f78 ...x 21:27:52.406177 192.168.0.193.32778 > 192.168.0.118.ftp: P 1:13(12) ack 42 win 5840 0x0000 4510 0040 9670 4000 4006 21b0 c0a8 00c1 E..@.p@.@.!..... 0x0010 c0a8 0076 800a 0015 5ed4 9ce8 292e 8a9c ...v....^...)... 0x0020 8018 16d0 edd9 0000 0101 080a 000e 0f5a ...............Z 0x0030 0007 1f78 5553 4552 206c 6565 6368 0d0a ...xUSER.leech.. 21:27:52.415487 192.168.0.118.ftp > 192.168.0.193.32778: P 42:76(34) ack 13 win 17304 0x0000 4500 0056 e0ac 4000 8006 976d c0a8 0076 E..V..@....m...v 0x0010 c0a8 00c1 0015 800a 292e 8a9c 5ed4 9cf4 ........)...^... 0x0020 8018 4398 4e2c 0000 0101 080a 0007 1fc5 ..C.N,.......... 0x0030 000e 0f5a 3333 3120 5061 7373 776f 7264 ...Z331.Password 0x0040 2072 6571 7569 7265 6420 666f 7220 6c65 .required.for.le 0x0050 6563 ec 21:27:52.415832 192.168.0.193.32778 > 192.168.0.118.ftp: . ack 76 win 5840 0x0000 4510 0034 9671 4000 4006 21bb c0a8 00c1 E..4.q@.@.!..... 0x0010 c0a8 0076 800a 0015 5ed4 9cf4 292e 8abe ...v....^...)... 0x0020 8010 16d0 7e5b 0000 0101 080a 000e 0f5b ....[.........[ 0x0030 0007 1fc5 .... 21:27:56.155458 192.168.0.193.32778 > 192.168.0.118.ftp: P 13:27(14) ack 76 win 5840 0x0000 4510 0042 9672 4000 4006 21ac c0a8 00c1 E..B.r@.@.!..... 0x0010 c0a8 0076 800a 0015 5ed4 9cf4 292e 8abe ...v....^...)... 0x0020 8018 16d0 90b5 0000 0101 080a 000e 10d1 ................ 0x0030 0007 1fc5 5041 5353 206c 3840 6e69 7465 ....PASS.l8@nite 0x0040 0d0a .. 21:27:56.179427 192.168.0.118.ftp > 192.168.0.193.32778: P 76:103(27) ack 27 win 17290 0x0000 4500 004f e0cc 4000 8006 9754 c0a8 0076 E..O..@....T...v 0x0010 c0a8 00c1 0015 800a 292e 8abe 5ed4 9d02 ........)...^... 0x0020 8018 438a 4c8c 0000 0101 080a 0007 1feb ..C.L........... 0x0030 000e 10d1 3233 3020 5573 6572 206c 6565 ....230.User.lee 0x0040 6368 206c 6f67 6765 6420 696e 2e0d 0a ch.logged.in... Данные, передаваемые по сети такими сервисами, как telnet, FTP и POP3, не шифруются. В предыдущем примере видно, как пользова- тель leech регистрируется на сервере FTP с помощью пароля l8@nite. Так как процедура аутентификации во время входа в систему тоже не шифруется, имена пользователей и пароли содержатся в информаци- онной части передаваемых пакетов. 254 0x400Сетевое взаимодействие Программа tcpdump – замечательный универсальный сниффер (пере- хватчик пакетов), но есть и специальные инструменты для сниффин- га, предназначенные для извлечения имен пользователей и паролей. Например, есть замечательная программа dsniff для выявления дан- ных, представляющих интерес, которую разработал Даг Сонг (Dug Song). reader@hacking:/booksrc $ sudo dsniff -n dsniff: listening on eth0 ----------------- 12/10/02 21:43:21 tcp 192.168.0.193.32782 -> 192.168.0.118.21 (ftp) USER leech PASS l8@nite ----------------- 12/10/02 21:47:49 tcp 192.168.0.193.32785 -> 192.168.0.120.23 (telnet) USER root PASS 5eCr3t 0x441 Сниффер сокетов прямого доступа В наших предыдущих примерах использовались сокеты потоков. При отправке и приеме через сокеты потоков данные инкапсулируются в соединении TCP/IP. При доступе к сеансовому уровню модели OSI (5) (см. рис. 4.1) операционная система берет на себя решение всех за- дач передачи, исправления ошибок и маршрутизации на более низком уровне. Возможность доступа к сети на более низких уровнях предо- ставляют сокеты прямого доступа (raw sockets). На этом нижнем уров- не видны все детали, с которыми программист должен работать явным образом. Сокеты прямого доступа создаются, если указать в качестве типа SOCK_RAW. В этом случае имеет значение выбор протокола, посколь- ку предлагается несколько его вариантов. В качестве протокола можно указать IPPROTO_TCP, IPPROTO_UDP или IPPROTO_ICMP. Ниже приведена про- грамма сниффинга TCP, использующая сокеты прямого доступа. raw_tcpsniff.c #include #include #include #include #include #include #include “hacking.h” int main(void) { int i, recv_length, sockfd; u_char buffer[9000]; 0x440 Анализ сетевых пакетов (сниффинг) 255 if ((sockfd = socket(PF_INET, SOCK_RAW, IPPROTO_TCP)) == -1) fatal(“in socket”); for(i=0; i < 3; i++) { recv_length = recv(sockfd, buffer, 8000, 0); printf(“Got a %d byte packet\n”, recv_length); dump(buffer, recv_length); } } Эта программа открывает сокет TCP прямого доступа и ожидает полу- чения трех пакетов, выводя каждый из них на устройство вывода с по- мощью функции dump(). Обратите внимание: буфер объявлен как пе- ременная типа u_char. Это вспомогательный тип из sys/socket.h, кото- рый раскрывается как unsigned char. Он удобен, потому что беззнако- вые переменные интенсивно используются в сетевом программирова- нии, а печатать каждый раз «unsigned» достаточно утомительно. После компиляции программа должна быть запущена с правами root, потому что обращение к сокетам прямого доступа требует прав супер- пользователя. Ниже приведен пример работы программы сниффинга во время посылки некоторого текста нашему простому серверу (simple_ server.c). reader@hacking:/booksrc $ gcc -o raw_tcpsniff raw_tcpsniff.c reader@hacking:/booksrc $ ./raw_tcpsniff [!!] Fatal Error in socket: Operation not permitted reader@hacking:/booksrc $ sudo ./raw_tcpsniff Got a 68 byte packet 45 10 00 44 1e 36 40 00 40 06 46 23 c0 a8 2a 01 | E..D.6@.@.F#..*. c0 a8 2a f9 8b 12 1e d2 ac 14 cf 92 e5 10 6c c9 | ..*...........l. 80 18 05 b4 32 47 00 00 01 01 08 0a 26 ab 9a f1 | ....2G......&... 02 3b 65 b7 74 68 69 73 20 69 73 20 61 20 74 65 | .;e.this is a te 73 74 0d 0a | st.. Got a 70 byte packet 45 10 00 46 1e 37 40 00 40 06 46 20 c0 a8 2a 01 | E..F.7@.@.F ..*. c0 a8 2a f9 8b 12 1e d2 ac 14 cf a2 e5 10 6c c9 | ..*...........l. 80 18 05 b4 27 95 00 00 01 01 08 0a 26 ab a0 75 | ....’.......&..u 02 3c 1b 28 41 41 41 41 41 41 41 41 41 41 41 41 | .<.(AAAAAAAAAAAA 41 41 41 41 0d 0a | AAAA.. Got a 71 byte packet 45 10 00 47 1e 38 40 00 40 06 46 1e c0 a8 2a 01 | E..G.8@.@.F...*. c0 a8 2a f9 8b 12 1e d2 ac 14 cf b4 e5 10 6c c9 | ..*...........l. 80 18 05 b4 68 45 00 00 01 01 08 0a 26 ab b6 e7 | ....hE......&... 02 3c 20 ad 66 6a 73 64 61 6c 6b 66 6a 61 73 6b | .< .fjsdalkfjask 66 6a 61 73 64 0d 0a | fjasd.. reader@hacking:/booksrc $ Эта программа может перехватывать пакеты, но она работает нена- дежно и будет пропускать пакеты, особенно при интенсивном трафи- ке. Кроме того, она перехватывает только TCP-пакеты; для перехва- 256 0x400Сетевое взаимодействие та UDP- или ICMP-пакетов нужно открывать дополнительные соке- ты прямого доступа. Другая серьезная проблема, связанная с сокета- ми прямого доступа, – это существенные различия между их реализа- циями в разных системах. Код для работы с сокетами прямого досту- па в Linux скорее всего не сможет функционировать в BSD или Solaris. Создать мультиплатформенное приложение для работы с сокетами пря- мого доступа практически невозможно. 0x442 Сниффер libpcap Решить проблему несовместимости сокетов прямого доступа на раз- ных платформах позволяет библиотека libpcap. Функции этой библио- теки используют в своей работе сокеты прямого доступа, но делают это правильно, учитывая конкретную архитектуру. Библиотека libpcap ис- пользуется как в tcpdump, так и в dsniff, что позволяет относительно просто компилировать эти программы на любой платформе. Напишем сниффер пакетов, используя не собственные функции, а те, которые есть в библиотеке libpcap. Они достаточно понятны интуитив- но, поэтому разберем их на примере следующего листинга. pcap_sniff.c #include #include “hacking.h” void pcap_fatal(const char *failed_in, const char *errbuf) { printf(“Fatal Error in %s: %s\n”, failed_in, errbuf); exit(1); } Сначала включаем файл pcap.h, который содержит разные структуры и макроопределения, используемые функциями pcap. Кроме того, я на- писал функцию pcap_fatal(), чтобы выводить сообщения о критических ошибках. Функции pcapзаписывают сообщения об ошибке и статусе в буфер, и данная функция отображает этот буфер для пользователя. int main() { struct pcap_pkthdr header; const u_char *packet; char errbuf[PCAP_ERRBUF_SIZE]; char *device; pcap_t *pcap_handle; int i; } Переменная errbuf – это уже упомянутый буфер ошибок, а его размер устанавливается в pcap.h равным 256. Переменная header – это структу- ра pcap_pkthdr, которая содержит дополнительные данные о перехвачен- ном пакете, такие как время перехвата и размер. Указатель pcap_handle 0x440 Анализ сетевых пакетов (сниффинг) 257 аналогичен дескриптору файла, но служит для ссылки на объект, веду- щий перехват пакетов. device = pcap_lookupdev(errbuf); if(device == NULL) pcap_fatal(“pcap_lookupdev”, errbuf); printf(“Sniffing on device %s\n”, device); Функция pcap_lookupdev() ищет устройство, на котором можно вести перехват пакетов. Устройство возвращается в виде указателя на стро- ку, находящуюся в статической памяти функции. В нашей системе это всегда будет устройство /dev/eth0, но на машине с BSD оно будет назы- ваться иначе. Если функция не может найти подходящий интерфейс, она возвращает NULL. pcap_handle = pcap_open_live(device, 4096, 1, 0, errbuf); if(pcap_handle == NULL) pcap_fatal(“pcap_open_live”, errbuf); Аналогично функциям открытия сокета и файла, функция pcap_open_ live() открывает устройство перехвата пакетов и возвращает его де- скриптор. Аргументами для этой функции служат устройство перехва- та, максимальный размер пакета, флаг неразборчивого режима и ука- затель на буфер ошибок. Мы хотим вести перехват в неразборчивом ре- жиме, поэтому флаг установлен в 1. for(i=0; i < 3; i++) { packet = pcap_next(pcap_handle, &header); printf(“Got a %d byte packet\n”, header.len); dump(packet, header.len); } pcap_close(pcap_handle); } Наконец, в цикле перехвата пакетов вызывается функция pcap_next(), которая захватывает очередной пакет. Этой функции передаются де- скриптор pcap_handle и указатель на структуру pcap_pkthdr, в которую она запишет результаты перехвата. Функция возвращает указатель на пакет и выводит его содержимое, получая размер из заголовка перехва- та. Интерфейс перехвата закрывается посредством pcap_close(). При компиляции этой программы нужно скомпоновать ее с библио- теками pcap. Это можно сделать с помощью флага -l при вызове GCC, как показано в следующем листинге. Библиотека pcap уже установлена в данной системе, поэтому библиотечные и включаемые файлы уже на- ходятся в стандартных каталогах, известных компилятору. reader@hacking:/booksrc $ gcc -o pcap_sniff pcap_sniff.c /tmp/ccYgieqx.o: In function `main’: pcap_sniff.c:(.text+0x1c8): undefined reference to `pcap_lookupdev’ pcap_sniff.c:(.text+0x233): undefined reference to `pcap_open_live’ 258 0x400Сетевое взаимодействие pcap_sniff.c:(.text+0x282): undefined reference to `pcap_next’ pcap_sniff.c:(.text+0x2c2): undefined reference to `pcap_close’ collect2: ld returned 1 exit status reader@hacking:/booksrc $ gcc -o pcap_sniff pcap_sniff.c -l pcap reader@hacking:/booksrc $ ./pcap_sniff Fatal Error in pcap_lookupdev: no suitable device found reader@hacking:/booksrc $ sudo ./pcap_sniff Sniffing on device eth0 Got a 82 byte packet 00 01 6c eb 1d 50 00 01 29 15 65 b6 08 00 45 10 | ..l..P..).e...E. 00 44 1e 39 40 00 40 06 46 20 c0 a8 2a 01 c0 a8 | .D.9@.@.F ..*... 2a f9 8b 12 1e d2 ac 14 cf c7 e5 10 6c c9 80 18 | *...........l... 05 b4 54 1a 00 00 01 01 08 0a 26 b6 a7 76 02 3c | ..T.......&..v.< 37 1e 74 68 69 73 20 69 73 20 61 20 74 65 73 74 | 7.this is a test 0d 0a | .. Got a 66 byte packet 00 01 29 15 65 b6 00 01 6c eb 1d 50 08 00 45 00 | ..).e...l..P..E. 00 34 3d 2c 40 00 40 06 27 4d c0 a8 2a f9 c0 a8 | .4=,@.@.’M..*... 2a 01 1e d2 8b 12 e5 10 6c c9 ac 14 cf d7 80 10 | *.......l....... 05 a8 2b 3f 00 00 01 01 08 0a 02 47 27 6c 26 b6 | ..+?.......G’l&. a7 76 | .v Got a 84 byte packet 00 01 6c eb 1d 50 00 01 29 15 65 b6 08 00 45 10 | ..l..P..).e...E. 00 46 1e 3a 40 00 40 06 46 1d c0 a8 2a 01 c0 a8 | .F.:@.@.F...*... 2a f9 8b 12 1e d2 ac 14 cf d7 e5 10 6c c9 80 18 | *...........l... 05 b4 11 b3 00 00 01 01 08 0a 26 b6 a9 c8 02 47 | ..........&....G 27 6c 41 41 41 41 41 41 41 41 41 41 41 41 41 41 | ‘lAAAAAAAAAAAAAA 41 41 0d 0a | AA.. reader@hacking:/booksrc $ Обратите внимание: перед текстом в пакете находится много байтов, и многие из них совпадают. Так как это «первичные» (raw) пакеты, то по большей части эти байты принадлежат заголовкам уровней Ether- net, IP и TCP. |