Коллектив авторов - Защита от хакеров корпоративных сетей

/* Lookup the router */

Помните, что ядро не предоставляет никакой подсказки относительно места нахождения маршрутизатора, и все, что фактически можно спросить у пользователя, – это его IP-адрес. В распоряжении разработчика предоставлен разумно гибкий интерфейс сетевого стека. Давайте воспользуемся им для посылки широковещательного запроса по протоколу разрешения адресов ARP с целью определения адреса аппаратных средств, соответствующих заданному IP-адресу, через который, как было сказано, следует направить пакет для маршрутизации. В нижеприведенном фрагменте кода видно, как на пустом месте следует создать пакет и отослать его:

libnet_init_packet(LIBNET_ETH_H + LIBNET_ARP_H, &newpacket);

Являясь простой оболочкой malloc, libnet_init_packet инициализирует заданное количество памяти (в этом случае необходимое количество памяти для заголовков Ethernet и ARP) и создает указатель newpacket на выделенную таким образом память:

libnet_build_ethernet(bcast_mac, /*eth->ether_dhost*/

user_mac, /*eth->ether_shost*/

NULL, /*extra crap to tack on*/

0, /*how much crap*/

newpacket);

Следует полностью определить базовую часть пакета: указать, куда пакет направляется, откуда поступил, тип пакета и т. д. В рассматриваемом случае пакет является широковещательным сообщением ARP из MAC-адреса пространства. Учитывая указатель newpacket правильным образом, указываем на заголовок Ethernet:

libnet_build_arp(ARPHRD_ETHER,

ETHERTYPE_IP,

ETHER_ADDR_LEN,

IPV4_ADDR_LEN,

ARPOP_REQUEST,

user_mac,

user_ip,

bcast_mac,

upstream_ip,

NULL,

0,

Библиотека libnet предоставляет полезные функции и учитывает почти все обрабатываемые выпуски программ, достаточные для заполнения полей пакета. При заполнении ARP-пакета требуется заполнить поля MAC-адреса пользователя и его IP-адрес, причем IP-адрес перечислен в списке upstream_ip и должен быть принят во внимание любым, кто может прослушать этот адрес. Следует отметить, что эта груда байтов к указателю newpacket непосредственно не добавляется. По протоколу Ethernet она передается следующему заголовку фиксированного размера:

i = libnet_write_link_layer(l, dev, newpacket, LIBNET_ETH_H

+

LIBNET_ARP_H);

if (verbose){

fprintf(stdout, “ARP REQUEST: Wrote %i bytes looking

for ” , i);

print_ip(stdout, upstream_ip);

Точно так же как машины отправляются в путь, пример отправляет Ethernet и ARP-заголовки, найденные им по указателю newpacket, а затем выполняет код, написанный для отладки. Функция Libnet_write_link_layer получает от библиотеки libnet номер соединения, адрес памяти отсылаемого пакета, как бы ни велик был пакет, а затем возвращает число успешно переданных байтов:

libnet_destroy_packet(&newpacket);

Если функция libnet_init_packet была аналогична функции malloc, то это просто свободно распространяемое приложение с лучшим названием.

Трах-тарах! Только что пакет был отослан. Что теперь дальше?

/* Get the next packet from the queue, */

while (1) {

packet = (u_char *) pcap_next(pcap, &pkthdr);

Обратите внимание на то, что pcap_next — простая функция: учитывая активный дескриптор файла libcpap и место для размещения пакета, функция pcap_next возвращает адрес памяти захваченного пакета. Эта память доступна для чтения и записи, что и было использовано в примере. Следует сделать некоторое замечание. То ли из-за опции IOCTL, то ли из-за особенностей платформы, на которой выполняется libpcap, но во время чтения пакета прерывание функции pcap_next блокируется. В противном случае цикл будет повторяться до тех пор, пока не будет завершен разбор пакета:

/*

* Make packet parseable – switching on

* eth->ether_type and ip->ip_p is also a valid

* strategy. All structs are defined in

* /usr/include/libnet/libnet-headers.h

*/

/* Layer 1: libnet_ethernet_hdr structs */

(char *)eth = (char *)packet;

/* Layer 2: libnet_arp_hdr / libnet_ip_hdr structs */

(char *)arp = (char *)ip = (char *)packet + LIBNET_ETH_H;

/*

* Layer 3: libnet_icmp_hdr / libnet_tcp_hdr /

* libnet_udp_hdr structs

*/

(char *)icmp = (char *)tcp = (char *)udp = (char *)packet +

LIBNET_ETH_H

Используемая в данном случае линия поведения очень проста. Каждая структура пакета выравнивается в области памяти, отведенной для его размещения, причем эта область точно такая же, как если этот пакет был заданного типа. Было бы глупо заполнить структуры неправильными данными, полагаясь лишь на выбор области памяти указателями eth->ether_type (на уровне канала передачи данных) или ip->ip_p (на сетевом уровне), которые указывают на структуру описания пакета. Если так сделать, то при ошибке в разборе пакетов будут утеряны важные данные segfaults. Например, при попытке получить порядковый номер TCP-пакета из области памяти, в которой на самом деле хранится UDP-пакет и у которого нет такого значения, ничего хорошего не получится. Но с другой стороны, рассмотренный способ достаточно гибок, потому что в общем случае только ядро операционной системы отважится прочитать эти данные. В конце концов, программе DoxRoute не очень интересно, как пользователь будет читать данный пакет. Одно важное предостережение относительно разбора пакетов: при захвате пакетов интерфейсу локального хоста не доступен заголовок Ethernet, поэтому не следует при чтении данных локального хоста пользоваться смещением LIBNET_ETH_H:

/* Handle ARPs: */

if (ntohs(eth->ether_type) == ETHERTYPE_ARP &&

arp->ar_op == htons(ARPOP_REQUEST) &&

!memcmp(arp->ar_tpa, user_ip, IPV4_ADDR_LEN)) {

/*

* IF: The ethernet header reports this as an

* ARP packet, the ARP header shows it a

* request for translation, and the address

* being searched for corresponds to this

* “stack”...

*

В этом месте программа ищет запросы ARP. Первое, что нужно сделать, – это удостовериться в том, что полученные данные действительно являются пакетом, содержащим нужный запрос. Для этого требуется пара надоедливых вещей. Во-первых, необходимо изменить порядок байтов в данных, на которые указывает указатель eth->ether_type, по крайней мере на системах с прямым порядком байтов. (Вполне возможно, что предложенный способ плохо работает на системах с обратным порядком байтов.) Это выполняется при помощи вызова функции ntohs, которая управляет переключением от сети к хосту. Затем следует проверить, что удаленная сторона осуществляет повторный запрос, повторно переключая порядок используемых байтов. На сей раз используется функция htons для представления ARP-запроса в присущий для сети формат. Наконец, коснемся вопроса о том, соответствует ли найденный ARP-запрос IP-адресу, присутствие которого искалось в сети для ее фальсификации. Это осуществляется при помощи инвертирования результата работы функции memcmp, возвращающей первый байт, которым отличаются два буфера. Причем нулевой код возврата означает, что различие между буферами не найдено, точно то, что нам и хотелось. Таким способом код возврата инвертируется в единичное значение:

memcpy(eth->ether_dhost, eth->ether_shost, ETHER_ADDR_LEN); memcpy(eth->ether_shost, user_mac, ETHER_ADDR_LEN);

Одной из действительно крутых вещей, которые можно сделать благодаря совместимости буферов libpcap и libnet, является то, что по желанию можно на месте переставлять пакеты в сети, а затем отослать их обратно без повторной инициализации памяти или передачи содержимого через какой-либо контекст или еще как-нибудь. (В этом нет ничего нового. Программы ядра операционной системы делают это годами. Но рассматриваемый случай – это случай нахождения в пространстве пользователя в предположении работы Netscape, mpg123 или еще чего-нибудь без имитации работы сетевой платы!) Поскольку делается попытка ответить отправителю Ethernet-пакета, поэтому просто и деструктивно копируем оригинальный адрес отправителя в поле адресата. Затем записываем в поле «хост-отправитель» пакета Ethernet MAC-адрес, который обязательно существует в сети: