Обфусцированный шеллкод, волк в овечьей шкуре (часть 1)
Волк в овечьей шкуре
Сегодня существует множество угроз, которые вызывают беспокойство у аналитика сетевой безопасности. Некоторые из угроз могут быть в определенной степени смягчены за счет использования различных аппаратных и программных решений. Хорошим примером этого может быть то, как вы защищаете от этого вездесущего вредителя; распределенная атака типа «отказ в обслуживании». Несколько поставщиков предложили несколько хороших аппаратных решений для этой сетевой атаки. Подобно другим поставщикам, они продают брандмауэры корпоративного класса для защиты корпоративной сети. Что общего у двух вышеупомянутых примеров, так это то, что решение предоставляется третьей стороной. Эти решения легко внедрить, проведя небольшое обучение на стороне поставщика для внутреннего персонала по сетевой безопасности.
Это подводит меня к теме, о которой я писал раньше; обучение аналитика сетевой безопасности. Без обучения сотрудников вашей сетевой безопасности, в обязанности которых входит защита ваших корпоративных киберактивов, они будут крайне неподготовлены к выполнению своих обязанностей. Один очень хороший пример того, как отсутствие обучения может повлиять на вас, — это то, о чем эта серия статей из трех частей. В частности, что такое обфускация шелл-кода и как она влияет на аналитика сетевой безопасности на вашей работе, который может не знать об этой угрозе.
Так в чем твоя точка зрения?
Смысл писать об обфускации шелл-кода и о том, как она может повлиять на плохо подготовленного аналитика, заключается в том, что эта угроза очень высокого уровня. Это тот, который обычно приводит к доступу на системном уровне или root в зависимости от вашей операционной системы. Большинство из нас, занимающихся компьютерной безопасностью, понимают, что большая часть серьезного ущерба вызвана переполнением буфера. Что происходит, так это то, что программа, такая как Apache или IIS, например, может иметь плохую проверку ввода в части своего кода. Это отсутствие проверки ввода, в свою очередь, приведет к тому, что программа не будет проверять, сколько записано в определенной части кода этой программы. Суть проблемы в том, что этой гипотетической строке кода назначен только определенный объем памяти. Затем злоумышленник, заметив (путем дизассемблирования кода), что проверка ввода отсутствует, просто перезапишет буфер этой функции. Проблема в том, что он также распространяется и на буфер другой функции. Оттуда эксплойт делает свое дело. Проще говоря, так и происходит.
Имея в виду вышеизложенное, мы задаемся вопросом: «Как злоумышленник может переполнить буфер функции?» Эта проблема решается как часть кода эксплойта злоумышленника, который состоит из нескольких компонентов. Обычно код эксплойта написан на C или C++, так как большинство тяжелых веб-приложений (таких как веб-серверы и операционные системы) написаны на этих языках. После компонента C или C++ вы найдете свой шеллкод. Есть несколько причин, по которым фактическая часть кода эксплойта написана на ASM. Самое главное, что писать на ASM меньше по размеру, чем на C. Кроме того, ассемблерный код определенно выполняется быстрее. То, что содержит ASM-часть этого эксплойта, является конечным результатом того, чего хочет разработчик эксплойта; cmd.exe или корневая оболочка. Теперь, получив эту обратную оболочку, разработчик эксплойта полностью распоряжается компьютером.
Что используется для переполнения буфера?
Возможно, вы помните, что буква «А» использовалась в качестве символа переполнения буфера в Code Red. Подавляющее большинство символов переполнения буфера очень похожи на вышеупомянутую букву А, но это может быть и любой другой символ. Например, в другой версии Code Red для переполнения использовался символ N. Хотя многим из вас, кто следит за системой обнаружения вторжений, может быть знаком символ 0x90.
(Всякий раз, когда вы видите 0x, вы должны знать, что следующие буквенно-цифровые символы находятся в шестнадцатеричной системе счисления). Это 0x90 переводится как функция NOP, также известная как «нет операции», и буквально означает именно это, когда инструкция выполняется процессором компьютера. Поэтому, когда компьютер обрабатывает эту инструкцию, он ничего не делает и продолжает обработку, пока не достигнет инструкции, которая заставит его что-то сделать. Эти символы будут отображаться как часть шестнадцатеричной полезной нагрузки в пакете. В приведенном ниже примере пакета буквенно-цифровые символы после 0x0000, то есть: 4500 0028, находятся в вышеупомянутой шестнадцатеричной системе счисления. Именно в этой части пакета вы заметите повторяющийся символ, такой как A или N для Code Red.
24.01.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..([email protected]
0x0010 xxxx xxxx b250 0019 24d7 9ce9 82ed fd66 …..P..$……f
0x0020 5010 4470 ce75 0000 0000 0000 0000 P.Dp.u……..
Этот повторяющийся шестнадцатеричный символ легко увидеть, и, что более важно, поставщикам систем обнаружения вторжений есть, для чего писать подпись. Возьмите приведенный выше пример и для ясности сделайте его похожим на:
24.01.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..([email protected]
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 просто написали подпись, ища эти общие шестнадцатеричные символы, повторяющиеся сверх определенного количества. Presto ваш IDS отключается, говоря, что он обнаружил попытку переполнения буфера. (Обычно, хотя для пакета должны соответствовать другие критерии, такие как номер порта назначения)
Давайте соберем все это вместе
Итак, теперь мы знаем, что подавляющее большинство кода эксплойта имеет то, что называется NOP-следом. Эта цепочка NOP используется, чтобы дать кодировщику эксплойта фактор обмана, на который нужно указать EIP, чтобы ЦП начал выполнять эти NOP, пока не столкнется с кодом эксплойта. Теперь видно, что в большинстве кодов эксплойтов этот NOP-код в основном состоит из шестнадцатеричного символа 0x90, и поставщикам систем обнаружения вторжений несложно создать сигнатуру. Эта буквенно-цифровая строка плюс номер порта назначения часто используется для формирования подписи.
Окончательно!
Что произойдет, если больше не будет салазок NOP для подписи поставщика? Именно здесь в игру вступает обфускация шеллкода. Разработчики эксплойтов, будучи очень умной группой, быстро поняли, что поставщики IDS создавали подписи на основе этого NOP-следа. Они начали думать о том, как победить эту очень эффективную контрмеру. Проблема заключалась в том, что им нужно было придумать другую инструкцию, которая ничего не делала с компьютером, поскольку процессор ее выполнял. По сути, им нужна была еще одна инструкция NOP. Что ж, как оказалось, разработчики этих эксплойтов тестировали, и исследования выявили целый ряд других идемпотентных инструкций. (идемпотент означает инструкцию или код операции, который не будет произвольно воздействовать на компьютер-жертву, т. е. не приведет к его сбою). По последним подсчетам, было около шестидесяти или около того других идемпотентных инструкций, которые можно было использовать вместо NOP, также известного как 0x90. В настоящее время обратите внимание, что я имею в виду только поставщика IDS, который пишет подпись на основе NOP-следа, а не говорит /bin/sh в содержимом ascii. Существуют и другие подписи, которые можно разработать на основе содержимого пакета ascii. Это завершает первую часть этой серии. Во второй части я покажу вам, как snort (экстраординарный IDS с открытым исходным кодом) видит эксплойт с NOP-следом. До тех пор!