Эта статья описывает, что такое shellcode и как он относится к вредоносному коду. Также объясняются некоторые усовершенствования в разработке вредоносного кода в попытках дальнейшего скрытия присутствия отдельных характеристик shellcode.
Если вы пропустили другие статьи в этой серии, пожалуйста, прочитайте:
Волк в шкуре овцы
Сегодня существует множество опасностей, которые касаются анализа сетевой безопасности. Некоторые из них могут быть уменьшены в какой-то степени при использовании различных аппаратных и программных решений. Хороший пример этого может быть то, как вы защищаетесь против вездесущих паразитов — атаки распределенного отказа в обслуживании. Некоторые производители выступают со своими аппаратными решениями для этих сетевых атак. Многие другие производители продают брандмауэры класса предприятия для помощи в защите корпоративной сети. Что эти два приведенных примера имеют общего – это то, что решение обеспечивается третьей стороной. Эти решения легко применяются при небольшом обучении внутреннего персонала сетевой безопасности производителем.
Это дало мне тему, о которой я писал ранее: обучение аналитика сетевой безопасности. Без обучения вашего персонала сетевой безопасности, который отвечает за защиту вашего корпоративного кибер-имущества, они будут печально неподготовлены для выполнения своих обязанностей. Один очень хороший пример того, как недостаток подготовки может нанести ущерб вам – это то, о чем пишут все серии статей третьих фирм. А именно, что такое shellcode затемнение, и как оно воздействует на аналитика сетевой безопасности в вашей работе, не знающего об этой угрозе.
Суть написания статьи о shellcode затемнении и о том, как оно влияет на плохо подготовленного аналитика, в том, что эта угроза является высокоуровневой. Это обычно отражается на доступе системного уровня или root, в зависимости от вашей операционной системе. Большинство из нас, кто связан с компьютерной безопасностью, знает, что основное высокоуровневое нарушение вызывается переполнением буфера. Случается, что программа, такая как, например, Apache или IIS, имеет плохой контроль ввода в части своего кода. Этот недостаток контроля ввод приводит к тому, что программа не проверяет, как много записано в определенной части кода программы. Проблема в том, что эта гипотетическая строка кода имеет определенное количество выделенной ей памяти. Атакующий затем узнает (через получение дизассемблированного кода), что здесь нет контроля ввода, и затем просто переписывает буфер этой функции. Проблема точно также перетекает в буфер другой функции. Из-за этого используя ее работу. Очень просто объяснить, что случается.
Помня приведенное выше, мы спросим сами себя: “хорошо, а как атакующий переполнит буфер функции?” Эта проблема создается, как часть кода, используемого атакующим, который имеет отдельные компоненты для этого. Обычно вредоносный код написан на C или C++, как и большинство тяжеловесных web-приложений (таких как web серверы и операционные системы), написанных на этих же языках. Следовательно, C или C++ компонент и является тем местом, где вы можете обнаружить ваш shellcode. Существует несколько причин, чтобы реально используемая часть кода была написана на ASM. Наиболее важная – в том, что написанное на ASM меньше написанного на C. Также, значительно быстрее выполняется собранный код. Какая ASM порция этого содержимого является конечным результатом зависит от того, что хочет разработчик; cmd.exe или root shell. Теперь, имея измененную shell, разработчик кода имеет свободный контроль над компьютером.
Вы можете помнить, что буква “A” использована в качестве символа переполнения буфера в Code Red. Значительное большинство символов переполнения буфера подобно вышеупомянутому символу A, но это может быть точно также любой другой символ. Например, другая версия Code Red использовала символ N для этого переполнения. Хотя большинство из вас, кто отслеживает системы распознавания вторжения, больше знакомы с символом 0x90.
(Везде, где вы увидите 0x, вам следует знать, что следующие буквенно-цифровые символы – это число в шестнадцатиричной системе счисления). Этот 0x90 транслируется в функцию NOP, или “нет операции”, и имеет смысл только когда инструкция исполняется компьютерным CPU. Так, когда компьютер обрабатывает эту инструкцию, он ничего не делает и обрабатывает эти инструкции, пока не достигнет инструкции, которая что-либо делает. Эти символы выявляются, как часть hex полезной нагрузки пакета. В приведенном ниже в качестве примера пакете буквенно-цифровые символы после 0x0000: 4500 0028 являются упомянутой шестнадцатиричной системой счисления. В этой части пакета вы можете заметить повторяющиеся символы, такие как A или N для Code Red.
01/24/2005 00:01:52.750789 xxx.xxx.xxx.xxx.45648 > xxx.xxx.xxx.xxx.25: . [tcp sum ok] ack 2196634982 win 17520 (DF) (ttl 120, id 46606, len 40)
0x0000 4500 0028 b60e 4000 7806 a451 xxxx xxxx E..(..@.x..Q.gh.
0x0010 xxxx xxxx b250 0019 24d7 9ce9 82ed fd66 …..P..$……f
0x0020 5010 4470 ce75 0000 0000 0000 0000 P.Dp.u……..
Эти повторы шестнадцатиричных символов легко заметить а для производителей систем распознавания вторжения очень важно что-нибудь для написания сигнатуры. Просмотрите пример вверху, а для большей ясности представим его в виде:
01/24/2005 00:01:52.750789 xxx.xxx.xxx.xxx.45648 > xxx.xxx.xxx.xxx.25: . [tcp sum ok] ack 2196634982 win 17520 (DF) (ttl 120, id 46606, len 40)
0x0000 4500 0028 b60e 4000 7806 a451 xxxx xxxx E..(..@.x..Q.gh.
0x0010 xxxx xxxx b250 0019 24d7 9ce9 82ed fd66 …..P..$……f
0x0020 nnnn nnnn nnnn nnnn nnnn nnnn nnnn nnnn P.Dp.u……..
Пожалуйста, заметьте, что это не psh/ack пакеты с допустимой полезной нагрузкой, а упрощенные, для примера.
В примере вверху легко увидеть серии из ‘n’ и в этом примере это представление символа, используемого для переполнения. Это тот символ, которым будет переписана функция, которая не имеет качественной проверки ввода. Итак, производители IDS просто записывают сигнатуру поиска для этих основных символов, состоящую из повторяющихся этих символов в количестве, превышающем обычное значение. Быстро ваши IDS ослабевают при выявлении попыток переполнения буфера. (Обычно даже если будет проверяться другие критерии пакета, такие как номер порта назначения)
Итак, теперь мы знаем, что подавляющее большинство вредоносного кода имеет так называемый NOP след. Этот NOP след используется для внедрения обманного действия, которое устанавливает EIP так, что CPU начинает исполнять эти NOP до тех пор, пока не достигнет вредоносного кода. Теперь видно, что большинство вредоносного кода имеет этот NOP след, в основном состоящий из шестнадцатиричного символа 0x90, и является легкой задачей для построения сигнатур производителями систем распознавания вторжения. Это буквенно-цифровая строка плюс номер порта назначения и являются часто используемой формой сигнатуры.
Что случится, если больше NOP след не вызовет срабатывания сигнатуры производителя? Тогда в самом деле вступит в игру shellcode затенение. Вредоносные разработчики были очень умными и быстро вычислили, что производители IDS делали сигнатуры, основанные на этом NOP следе. Они придумали способ обыграть этот высокоэффективный счетчик-измеритель. Они в самом деле искали другую инструкцию. Которая не делала бы ничего на компьютере, когда ее исполнял CPU. В общем, они искали другую NOP инструкцию. Итак, это заставило этих вредоносных разработчиков тестировать, и они обнаружили целую кучу других идемпотентных инструкций (идемпотент означает инструкцию или opcode, которые безнаказанно наносят вред компьютеру-жертве, т.е. ломают его). По крайней мере, их количество было около шестидесяти, или другие идемпотентные инструкции, которые могли использоваться вместо NOP, известной как 0x90. В тоже время заметьте, пожалуйста, что я только ссылался на производителей IDS, написавших сигнатуры, основанные на NOP следе, и не говорил об /bin/sh в ascii содержимом. Существуют другие сигнатуры, которые могут быть разработаны, основываясь на ascii содержимом пакетов. Этим я закончу первую часть в этой серии. Во второй части я покажу вам, как snort (особенный IDS с открытым кодом) видит вредоносный код с NOP следом. До встречи!
Источник www.windowsecurity.com
Tags: apache, redirect, search