какие угрозы связаны с использованием протокола dhcp
Безопасность DHCP в Windows 10: разбираем критическую уязвимость CVE-2019-0726
С выходом январских обновлений для Windows новость о критически опасной уязвимости CVE-2019-0547 в DHCP-клиентах всколыхнула общественность. Подогревали интерес высокий рейтинг CVSS и тот факт, что Microsoft не сразу опубликовал оценку эксплуатабельности, усложнив тем самым пользователям решение о неотложном обновлении систем. Некоторые издания даже предположили, что отсутствие индекса можно интерпретировать как свидетельство о том, что уже в ближайшее время появится рабочий эксплойт.
Такие решения, как MaxPatrol 8, умеют выявлять уязвимые для определенных атак компьютеры в сети. Другие решения, такие как PT NAD, обнаруживают сами подобные атаки. Чтобы это стало возможным, необходимо описывать как правила выявления уязвимостей в продуктах, так и правила обнаружения атак на эти продукты. В свою очередь, чтобы это стало возможным, необходимо для каждой отдельно взятой уязвимости выяснять вектор, способ и условия ее эксплуатации, то есть буквально все детали и нюансы, связанные с эксплуатацией. Требуется гораздо более полное и глубокое понимание, нежели то, которое обычно можно составить по описаниям на сайтах вендоров или в CVE, вроде:
Уязвимость проявляется по той причине, что операционная система некорректно обрабатывает объекты в памяти.
Итак, чтобы добавить в продукты компании правила обнаружения атак на новоиспеченную уязвимость в DHCP, а также правила выявления устройств, ей подверженных, следовало разобраться в деталях. В случае бинарных уязвимостей для проникновения в суть лежащих в их основе ошибок часто используется patch-diff, то есть сравнение изменений, внесенных в бинарный код приложения, библиотеки или ядра операционной системы конкретным патчем, обновлением, исправляющим эту ошибку. Но первый этап — это всегда рекогносцировка.
Примечание: Чтобы перейти непосредственно к описанию уязвимости, минуя лежащие в ее основе концепты DHCP, вы можете пропустить первые несколько страниц и обратиться сразу к разделу «Функция DecodeDomainSearchListData».
Рекогносцировка
Обращаемся в поисковик и просматриваем все известные на данный момент детали уязвимости. На этот раз деталей минимум, и все они являются вольными переработками информации, почерпнутой из оригинальной публикации на сайте MSRC. Такая ситуация вполне типична для ошибок, обнаруженных специалистами Microsoft во время внутреннего аудита.
Из публикации выясняем, что перед нами уязвимость типа memory corruption, содержащаяся как в клиентских, так и в серверных системах Windows 10 version 1803 и проявляющаяся в тот момент, когда злоумышленник отправляет специальным образом сформированные ответы DHCP-клиенту. Спустя пару дней с того момента на странице появятся также и индексы эксплуатабельности:
Как видно, MSRC проставили оценку «2 — Exploitation Less Likely». Это значит, что ошибка с большой вероятностью либо неэксплуатабельна вовсе, либо эксплуатация сопряжена с такими сложностями, преодоление которых потребует чересчур высоких трудозатрат. Следует признать, что Microsoft не свойственно занижать такие оценки. Отчасти на это влияет риск репутационных потерь, отчасти — некоторая независимость центра реагирования в рамках компании. Поэтому предположим: раз в отчете угроза эксплуатации указана как маловероятная, наверняка так оно и есть. Собственно, на этом можно было бы завершить разбор, но не будет лишним перепроверить и хотя бы выяснить, в чем заключалась уязвимость. В конечном счете, несмотря на всю бесспорную индивидуальность, ошибки имеют свойство повторяться и проявлять себя в других местах.
Среди всего множества файлов поиск обнаруживает несколько подходящих под фильтр библиотек, которые мы сравниваем с их версиями на непропатченной системе. Библиотека dhcpcore.dll выглядит наиболее многообещающе. При этом BinDiff выдает минимальные изменения:
Собственно, отличные от косметических правки внесены в одну-единственную функцию — DecodeDomainSearchListData. Если вы хорошо знакомы с протоколом DHCP и его не слишком часто используемыми опциями, то уже можете предположить, что за список обрабатывает эта функция. Если же нет, то переходим ко второму этапу — изучению протокола.
DHCP и его опции
DHCP (RFC 2131 | wiki) — это расширяемый протокол, способность к пополнению возможностей которого обеспечивается полем options. Каждая опция описывается уникальным тегом (номером, идентификатором), размером, занимаемым данными, содержащимися в опции, и самими данными. Подобная практика типична для сетевых протоколов, и одной из таких «имплантированных» в протокол опций является Domain Search Option, описанная в RFC 3397. Она позволяет DHCP-серверу устанавливать на клиентах стандартные окончания доменных имен, которые будут использоваться в качестве DNS-суффиксов для настраиваемого таким образом соединения.
Пусть, для примера, на нашем клиенте были заданы следующие окончания имен:
Тогда при любой попытке определить адрес по доменному имени в DNS-запросы будут подставляться по очереди суффиксы из этого списка до тех пор, пока не будет найдено успешное отображение. Например, если пользователь ввел ru в адресной строке браузера, то будут сформированы DNS-запросы сначала для ru.microsoft.com, затем для ru.wikipedia.org:
На самом деле, современные браузеры чересчур умные, а потому на имена, не похожие на FQDN, реагируют перенаправлением в поисковик. Поэтому ниже прилагаем вывод менее избалованных утилит:
Читателю могло показаться, что в этом и состоит уязвимость, ведь сама по себе возможность подменять DNS-суффиксы с помощью DHCP-сервера, каковым может себя идентифицировать любое устройство в сети, представляет угрозу для клиентов, запрашивающих какие бы то ни было параметры сети по DHCP. Но нет: как следует из RFC, это считается вполне легитимным, документированным поведением. Собственно, DHCP-сервер по сути своей является одним из тех доверенных компонентов, которые могут оказывать сильное влияние на обращающиеся к ним устройства.
Опция Domain Search
Domain Search Option имеет номер 0x77 (119). Как и все опции, она кодируется однобайтовым тегом с номером опции. Как и у большинства прочих опций, сразу за тегом идет однобайтовый размер следующих за размером данных. Экземпляры опции могут присутствовать в DHCP-сообщении более одного раза. В этом случае данные со всех таких секций конкатенируются в той последовательности, в которой встречаются в сообщении.
В представленном примере, взятом из RFC 3397, данные разбиты на три секции, каждая по 9 байт. Как несложно понять из картинки, имена поддоменов в полном доменном имени кодируются однобайтовой длиной имени, непосредственно за которой следует само имя. Заканчивается кодирование полного доменного имени нулевым байтом (то есть нулевым размером имени поддомена).
Помимо этого, в опции используется простейший метод сжатия данных, а точнее, просто точки повторной обработки (reparse points). Вместо размера доменного имени поле может содержать значение 0xc0. Тогда следующий за ним байт задает смещение относительно начала данных опции, по которому следует искать окончание доменного имени.
Таким образом, в рассматриваемом примере закодирован список из двух доменных суффиксов:
Функция DecodeDomainSearchListData
Итак, опция DHCP под номером 0x77 (119) позволяет серверу настраивать на клиентах DNS-суффиксы. Но не на машинах с операционными системами семейства Windows. Системы от Microsoft традиционно игнорировали эту опцию, поэтому исторически окончания DNS-имен в случае необходимости накатывались через групповые политики. Так продолжалось до недавнего времени, когда в очередном релизе Windows 10, версии 1803, была добавлена обработка для Domain Search Option. Судя по названию функции в dhcpcore.dll, в которую были внесены изменения, именно в добавленном обработчике и кроется рассматриваемая ошибка.
Приступаем к работе. Причесываем немного код и выясняем следующее. Процедура DecodeDomainSearchListData, в полном соответствии с названием, декодирует данные из Domain Search Option поступившего от сервера сообщения. На входе она получает упакованный описанным в предыдущем пункте способом массив данных, а на выходе генерирует нуль-терминированную строку, содержащую список окончаний доменных имен, разделенных запятыми. Например, данные из примера выше эта функция преобразует в строку:
Вызывается DecodeDomainSearchListData из процедуры UpdateDomainSearchOption, которая прописывает возвращенный список в значение «DhcpDomainSearchList» ключа реестра:
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\
хранящего основные параметры конкретного сетевого интерфейса.
Функция DecodeDomainSearchListData отрабатывает за два прохода. На первом проходе она выполняет все действия, кроме записи в выходной буфер. Таким образом, первый проход посвящен подсчету размера памяти, необходимого для размещения возвращаемых данных. На втором проходе уже происходит выделение памяти под эти данные и заполнение выделенной памяти. Функция довольно невелика, порядка 250 инструкций, и основная ее работа заключается в обработке каждого из трех возможных вариантов представленного во входящем потоке символа: 1) 0x00, 2) 0xc0, или 3) все остальные значения. Предположительное исправление ошибки, связанной с DHCP, по большому счету сводится к добавлению в начале второго прохода проверки размера результирующего буфера. Если этот размер равен нулю, то память под буфер не выделяется и функция сразу завершает исполнение и возвращает ошибку:
Получается, уязвимость проявляет себя в тех случаях, когда размер целевого буфера оказывается равен нулю. При этом в самом начале выполнения функция проверяет входящие данные, размер которых не может быть меньше двух байтов. Стало быть, для эксплуатации требуется подобрать таким образом сформированную непустую опцию доменных суффиксов, чтобы размер выходного буфера был нулевым.
Эксплуатация
Первым делом в голову приходит мысль, что можно использовать описанные ранее reparse points для того, чтобы непустые данные на входе генерировали пустую строку на выходе:
Сервер, настроенный посылать в ответе опцию с таким содержимым, действительно вызовет access violation на необновленных клиентах. Происходит это по следующей причине. На каждом шаге, когда функция разбирает часть полного доменного имени, она копирует ее в целевой буфер и ставит после нее точку. В примере, взятом из RFC, в буфер будут скопированы данные в следующем порядке:
Затем, когда во входных данных встречается нулевой размер домена, функция заменяет предыдущий символ целевого буфера с точки на запятую:
и продолжает разбор:
По окончании входных данных остается лишь заменить последнюю запятую на нулевой символ и получается готовая к записи в реестр строка:
Что же происходит в случае, когда атакующий отправляет сформированный описанным способом буфер? Если разобраться в примере, то видно, что список, содержащийся в нем, состоит из одного элемента — пустой строки. На первом проходе функция подсчитывает размер данных на выходе. Так как данные не содержат ни одного ненулевого доменного имени, то размер равен нулю.
На втором проходе происходит выделение блока динамической памяти для размещения данных в нем и копирование самих данных. Но функция разбора сразу встречает нулевой символ, означающий конец доменного имени, а потому, как и было сказано, заменяет предыдущий символ с точки на запятую. И здесь мы сталкиваемся с проблемой. Итератор целевого буфера находится в нулевой позиции. Предыдущего символа нет. Предыдущий символ принадлежит заголовку блока динамической памяти. И этот самый символ будет заменен на 0x2c, то есть на запятую.
Впрочем, так происходит только на 32-битных системах. Использование unsigned int для хранения текущей позиции итератора целевого буфера вносит свои коррективы в обработку на x64-системах. Обратим более пристальное внимание на кусок кода, отвечающий за запись запятой в буфер:
Вычитание единицы из текущей позиции происходит с использованием 32-битного регистра eax, в то время как при адресации буфера код обращается к полному 64-битному регистру rax. В архитектуре AMD64 любые операции с 32-битными регистрами обнуляют старшую часть регистра. Это означает, что в регистре rax, содержавшем прежде нуль, после вычитания будет храниться не значение –1, а 0xffffffff. Следовательно, на 64-битных системах значение 0x2c будет записываться по адресу buf[0xffffffff], то есть далеко за границами выделенной под буфер памяти.
Полученные данные хорошо согласуются с оценкой эксплуатабельности от Microsoft, ведь для того, чтобы воспользоваться данной уязвимостью, атакующему требуется научиться удаленно производить heap spraying на DHCP-клиенте и при этом иметь достаточный контроль над распределением динамической памяти, чтобы запись заранее заданных значений, а именно запятой и нулевого байта, производилась в подготовленный адрес и приводила к контролируемым негативным последствиям. В противном случае запись данных по невыверенному адресу будет иметь в качестве последствия падение процесса svchost.exe вместе со всеми хостящимися в нем на этот момент сервисами — и дальнейший перезапуск этих сервисов операционной системой. Факт, который злоумышленники в определенных условиях также могут использовать себе во благо.
Вот, казалось бы, и все, что можно сказать об исследуемой ошибке. Только остается ощущение, будто это далеко не конец. Будто мы не рассмотрели все варианты. Должно быть нечто большее, что скрыто в этих строках.
CVE-2019-0726
Вероятно, так оно и есть. Если пристально посмотреть на вид данных, провоцирующих ошибку, и сопоставить их с тем, как именно эта ошибка возникает, можно заметить, что список доменных имен может быть изменен таким образом, что результирующий буфер будет ненулевого размера, но попытка записи за его пределы все так же будет производиться. Для этого первый элемент в списке должен быть пустой строкой, а все остальные могут содержать нормальные доменные окончания. Например:
Теперь следует подтвердить полученные теоретические результаты на практике. Моделируем ситуацию, в которой DHCP-сервер шлет в ответ на запрос от клиента сообщение с представленной опцией, и сразу же ловим исключение при попытке записи запятой в позицию 0xffffffff выделенного под результирующую строку буфера:
Здесь регистр r8 содержит указатель на входящие опции, rdi — адрес выделенного целевого буфера, а rax — позицию в этом буфере, в которую нужно записать символ. Такие результаты мы получили на полностью обновленной системе (по состоянию на январь 2019 года).
Пишем об обнаруженной проблеме в Microsoft и… они теряют письмо. Да, такое иногда случается даже с зарекомендовавшими себя вендорами. Никакая система не идеальна, и приходится в этом случае искать другие пути коммуникации. Поэтому неделю спустя, не получив даже автоответа за это время, связываемся напрямую с менеджером через Twitter и по результатам нескольких дней анализа заявки выясняем, что отправленные детали не имеют никакого отношения к CVE-2019-0547 и представляют собой самостоятельную уязвимость, для которой будет заведен новый CVE-идентификатор. Еще месяц спустя, в марте, выходит соответствующее исправление, а ошибка получает номер CVE-2019-0726.
Вот так можно иногда в попытках разобраться в подробностях уязвимости 1-day случайно обнаружить 0-day, просто доверившись своей интуиции.
Автор: Михаил Цветков, специалист отдела анализа приложений Positive Technologies.
Атакуем DHCP
В данной статье мы расскажем, как эксплуатировать ShellShock на клиенте DHCP и получить на нем полноценный reverse или bind shell. Интернет пестрит статьями, повествующими о возможностях эксплуатации shellshock на DHCP-клиентах. Есть даже статьи о том, как получить reverse shell на DHCP-клиенте. Однако, стабильно и повсеместно работающего инструмента для получения shell мы еще не встречали. Те, кто в теме, возможно, нового здесь не увидят, но не исключено, что вам будет интересно узнать, как нам удалось автоматизировать получение reverse и bind shell в условиях фильтрации и экранирования символов на стороне DHCP-клиента. Кроме того, мы расскажем и о том, чем вообще может быть интересен протокол DHCP.
Протокол DHCP применяется для автоматического назначения IP-адреса, шлюза по умолчанию, DNS-сервера и т.д. В качестве транспорта данный протокол использует UDP, а это значит, что мы можем без особых проблем подменять все интересующие нас поля в сетевом пакете, начиная с канального уровня: MAC-адрес источника, IP-адрес источника, порты источника — то есть все, что нам хочется.
DHCPDISCOVER Клиент отправляет широковещательный сетевой пакет с целью найти DHCP-сервер в сети, при этом с канальным уровнем все понятно и о нем писать дальше не будем, сетевой — исходя из собственного опыта, здесь может быть всякое — зависит от клиента, но должно быть:
SRC IP: 0.0.0.0, DST IP: 255.255.255.255.
На транспортном уровне все запросы отправляются так:
SRC PORT: 68, DST PORT: 67
Соответственно, когда сервер отвечает клиенту:
SRC PORT: 67, DST PORT: 68
Контрольную сумму UDP можно не считать. Мы не встречали ни одного DHCP-сервера, который бы ее проверял, да и сетевое оборудование пропускает пакеты с нулевым значением UDP checksum без проблем. В первом байте прикладного уровня (поле op — тип сообщения) клиент выставляет значение — 0х01 (BOOTREQUEST — запрос от клиента к серверу). На остальных полях пакета не будем останавливаться, поскольку их описание, длина и значения есть в RFC и в WIKI. В запросе от клиента нам также интересно поле xid (Transaction ID — рандомное число размером 4 байта по смещению 0х04 от начала прикладного уровня в пакете). Если сервер в ответе выставит поле xid не равным xid клиента, то клиент отбросит ответ от сервера, поскольку посчитает, что этот ответ в другой транзакции. Остановимся на DHCP-опциях пакета. Всего их 256, а полный список можно найти здесь или тут. Клиент обязательно выставляет опцию с кодом 53 (DHCP message type тип DHCP сообщения) равной 0х01, это значит, что данный пакет предназначен для нахождения DHCP-сервера, и опцию 55 (Parameter Request List список запрашиваемых у сервера параметров, например адрес шлюза, маска подсети, DNS-серверы и т.д.).
Вот так выглядит этот запрос в WireShark:
DHCPOFFER Сервер получает запрос от клиента и отправляет ему предложение. На сетевом уровне в качестве SRC IP сервер выставляет свой IP-адрес, в DST IP должно быть: 255.255.255.255, но это не всегда так. В DST IP также может быть выставлен IP-адрес, выделенный клиенту, или IP-адрес ретранслятора, если тот участвует в процессе. Вы спросите, а как же пакет доходит до клиента, если у него еще нет IP-адреса? Все просто: в DHCPDISCOVER- и DHCPREQUEST-запросах, в поле chaddr (Сlient MAC address) клиент указывает свой MAC-адрес.
DHCPREQUEST Клиент отправляет серверу запрос на получение сетевых параметров. На сетевом уровне должно быть так: SRC IP: 0.0.0.0 DST IP: 255.255.255.255 но может быть и так: в SRC IP выставляется IP-адрес, который назначил сервер в своем предложении (поле yiaddr), а в DST IP выставляется IP-адрес, который расположен в опции предложения сервера с кодом 54 (Server Identifier). DHCP-опции в этом запросе не отличаются от DHCPDISCOVER-запроса, за исключением опции с кодом 53 (DHCP message type тип DHCP сообщения), равной 0х03 — это значит, что данный пакет предназначен для запроса параметров от DHCP-сервера. И еще клиент добавляет в запрос опцию с кодом 54 (Server Identifier), поскольку уже знает IP-адрес сервера, а также опцию с кодом 50 (Requested IP address). Кроме того, клиент может выставить опцию 12(Host Name Option свое имя хоста) и т.п.
Далее, клиент с помощью протокола ARP пытается обнаружить конфликт IP-адресов в локальной сети (Address Conflict Detection). Если конфликт не найден, клиент выставляет полученные из DHCPACK параметры сетевому интерфейсу. Если обнаружен, клиент рассылает широковещательное сообщение отказа DHCP DHCPDECLINE, после чего процедура получения IP-адреса повторяется.
Также у протокола DHCP есть еще одна особенность: если клиент ранее отправлял запрос DHCPDISCOVER, то при повторном подключении к той же сети клиент сразу отправляет DHCPREQUEST; при этом в DHCP-опции с кодом 50 (Requested IP address) выставляется IP-адрес, полученый ранее.
Остановимся на упомянутом DHCPDECLINE подробнее. На практике это выглядит так:
Клиент отправляет DHCPREQUEST, поскольку уже подключался к этой сети. Transaction ID: 0x825b824a; Requested IP: 192.168.1.171; Client MAC address: 08:00:27:ce:7a:64
Сервер отвечает DHCPACK.
Transaction ID: 0x825b824a; yiaddr: 192.168.1.171; siaddr: 192.168.1.1; router: 192.168.1.1
Клиент с помощью протокола ARP узнает MAC-адрес шлюза, а далее, через тот же ARP, пытается обнаружить конфликт IP-адресов в локальной сети (Address Conflict Detection). Запрос выглядит так:
sender mac: 08:00:27:ce:7a:64; sender ip: 0.0.0.0; target mac: 00:00:00:00:00:00; target ip: 192.168.1.171
Хост с IP-адресом 192.168.1.171 отвечает на ARP-запрос.
Клиент выявил конфликт IP-адресов в сети и отправляет широковещательный DHCPDECLINE.
Transaction ID: 0x825b824a; Requested IP: 192.168.1.171; ciaddr: 192.168.1.171
Процедура получения IP-адреса повторяется, но уже с другим Transaction ID: 0x713a0fe7. Вы обратили внимание на пакеты с номерами 89, 101, 106, 136 и 151? Если да, то наверняка поняли, что на этот раз сервер выделил клиенту IP-адрес 192.168.1.172 и перед этим DHCP-сервер сам с помощью того же ARP (пакеты с номерами 89, 101, 106: Who has 192.168.1.172? Tell 192.168.1.1 ) убедился, что IP-адрес 192.168.1.172 свободен, и только потом отправил DHCPOFFER. После этого клиент еще раз попытался выявить конфликт IP-адресов (пакеты с номерами 136, 151: Who has 192.168.1.172? Tell 0.0.0.0 ).
Мы уже знаем, что клиент, подключившись хотя бы раз к сети, будет отправлять только DHCPREQUEST-запрос, выставляя при этом в Requested IP адрес, который получил ранее. Но что если DHCP-сервер уже выделил этот IP-адрес, поменялась конфигурация или адресация, и сервер не может дать клиенту этот адрес? Для этого существует тип сообщения DHCPNAK. Работает он следующим образом:
Клиент отправляет DHCPREQUEST.
Transaction ID: 0xa7ddc5cb; Requested IP: 192.168.1.14
В настройках сервера указан диапазон, в котором он может выделять IP-адрес, но тот, который запросил клиент, не входит в данный диапазон, поэтому сервер отправляет DHCPNAK.
Transaction ID: 0xa7ddc5cb; Message: address not available
Процедура получения IP-адреса повторяется, но уже с другим Transaction ID: 0xcfbf77a9.
Перейдем к shellshock
Про то, как и почему работает shellshock, писать нет никакого смысла, ведь эта уязвимость — одна из самых популярных, и о ней есть великое множество статей. Лучше остановимся на моменте, как получить shell на клиенте DHCP, в случае, если мы выступим в роли DHCP-сервера.
В какие поля и опции можно инъектировать?
Ответ: практически в любые! Вот список кодов DHCP-опций, в которые возможно инъектировать (проверено на NetworkManager из состава CentOS 6.5): 14, 18, 43, 56, 60, 61, 62, 63, 64, 66, 67, 77, 80, 82, 83, 84, 86, 87, 90, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 113, 114, 115, 116, 117, 120, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225, 226, 227, 228, 229, 230, 231, 232, 233, 234, 235, 236, 237, 238, 239, 240, 241, 242, 243, 244, 245, 246, 247, 248, 250, 251, 253.
В нашем PoC мы будем использовать DHCP-опцию с кодом 114 (URL). Почему? Потому, что ее длина — вариативна (максимальная длина — 256 байт), а также потому, что ее все используют. Ее описание еще есть здесь. Существует даже статья о том, как с помощью этой опции обновить уязвимые к shellshock системы 🙂
Какие у нас ограничения?
Ответ: их много, слишком много!
И что тогда делать?
Ответ: обходить ограничения!
Для обхода фильтра мы должны выполнить все одной командой. Сделаем это так:
Здесь на вход интерпретатора /bin/sh мы подаем вывод /usr/bin/base64, которая декодирует строку Base64String. Таким образом, мы использовали уже 34 байта, длина Base64String не должна превышать 222 байтов.
А что будет в Base64String? Не забываем про четвертое ограничение, поэтому в первую очередь выставим IP-адрес интерфейсу командой:
Эта команда накладывает на нас еще одно ограничение: мы должны знать имя интерфейса, которому выставляем IP-адрес. По умолчанию, в старых версиях Linux, на которых еще есть shellshock, первый сетевой интерфейс называется eth0, так что ориентируемся на него. Еще в эту строку мы должны поместить reverse shell или bind shell.
Для reverse shell будем использовать стандартный shell с использованием nc:
Для reverse shell также можно использовать команду отсюда:
Для bind shell будем использовать /cmd/unix/bind_awk из состава Metasploit, как один из наиболее коротких: