Обфусцированный шеллкод, волк в овечьей шкуре (часть 3)

Во второй части этой серии статей мы видели, что поставщики систем обнаружения вторжений будут использовать наличие NOP, также известного как 0x90, в качестве компонента при создании сигнатур для эксплойтов переполнения буфера. Хотя это не единственный компонент подписи, это один из тех, который легко распознается большинством аналитиков сетевой безопасности. Это подводит нас к тому моменту, когда мы вырезаем 0x90 и помещаем на его место какую-то другую функцию или символ. Наша цель при этом — посмотреть, как отреагирует система обнаружения вторжений. Будет ли он по-прежнему воспринимать это как попытку переполнения буфера или нет? Во время моего исследования этой интересной области разработки эксплойтов я наткнулся на список идемпотентных замен, предоставленный Dragos Ruiu из Cansecwest. Именно из этого списка мы выберем новый и незаметный снегоход.

Если вы помните, наши старые сани NOP выглядели так:

/* bindshell без сбоя RPC, определяемый порт создания */
"x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"
"x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"
"x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"
"x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"
"x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"
"x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"
"x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"
"x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"
"x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"
"x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"
"x90x90x90x90x90x90x90xebx19x5ex31xc9x81xe9x89xff"

Таким образом, с приведенным ниже неполным списком мы создадим себе новый снегоход с другой функцией. А именно, мы будем использовать 0x42 или, как показано ниже, функцию «inc %edx». EDX — это регистр общего назначения в ассемблере, а «inc» означает приращение. Функция «inc» и противоположная ей функция «dec» широко используются в программировании на ассемблере. Список, представленный ниже, можно полностью просмотреть здесь. Обратите внимание, что первый столбец, показанный ниже, относится к архитектуре системы, например: IA32 — это 32-разрядная архитектура Intel. Второй столбец относится к фактическому шестнадцатеричному значению инструкции. Столбец после - это фактическая инструкция по ассемблеру, т.е. inc %eax означает, что значение в регистре eax будет увеличиваться, а последний столбец - это инструкция, представленная в ASCII.

Что ж, теперь мы создадим наш новый снегоход и протестируем его на нашей лабораторной машине с снова запущенным Snort, чтобы посмотреть, о чем он будет предупреждать. Но сначала давайте посмотрим, как выглядят наши недавно запутанные сани:

/* bindshell без сбоя RPC, определяемый порт создания */
"x42x42x42x42x42x42x42x42x42x42x42x42x42x42x42x42"
"x42x42x42x42x42x42x42x42x42x42x42x42x42x42x42x42"
"x42x42x42x42x42x42x42x42x42x42x42x42x42x42x42x42"
"x42x42x42x42x42x42x42x42x42x42x42x42x42x42x42x42"
"x42x42x42x42x42x42x42x42x42x42x42x42x42x42x42x42"
"x42x42x42x42x42x42x42x42x42x42x42x42x42x42x42x42"
"x42x42x42x42x42x42x42x42x42x42x42x42x42x42x42x42"
"x42x42x42x42x42x42x42x42x42x42x42x42x42x42x42x42"
"x42x42x42x42x42x42x42x42x42x42x42x42x42x42x42x42"
"x42x42x42x42x42x42x42x42x42x42x42x42x42x42x42x42"
"x42x42x42x42x42x42x42xebx19x5ex31xc9x81xe9x89xff"

Вы должны быть очень осторожны, когда заменяете предыдущую 0x90 на другую идемпотентную функцию, такую как 0x42. Вы должны убедиться, что вы вставили точно такое же их количество, потому что вы не хотите случайно написать какой-то другой действительный код. Если вы сделаете это, код может не работать, как предполагалось изначально. Итак, теперь, когда новый салазок написан и код успешно скомпилирован, пришло время снова попробовать его против Snort.

[**] [1:2351:8] Попытка переполнения пути NETBIOS DCERPC ISystemActivator с прямым порядком байтов [**]

[Классификация: Попытка получить права администратора] [Приоритет: 1]

28.01-11:15:21.861046 192.168.1.102:1045 -> 192.168.1.101:135
TCP TTL:64 TOS:0x0 ID:798 IpLen:20 DgmLen:1500 DF
***A**** Seq: 0xB498EE5 Подтверждение: 0x7B4CD8CA Выигрыш: 0x5B4 TcpLen: 32
Опции TCP (3) => NOP NOP TS: 12684682 1849

[Внешняя ссылка => http://cgi.nessus.org/plugins/dump.php3?id=11808][Внешняя ссылка => http://www.microsoft.com/technet/security/bulletin/MS03-026.mspx] [Внешняя ссылка => http://cve.mitre.org/cgi-bin/cvename.cgi?name=2003-0352][Внешняя ссылка => http://www.securityfocus.com/bid/8205]

Что ж, мы можем видеть из сгенерированного выше предупреждения, что Snort действительно воспринял этот новый скрытый эксплойт как попытку переполнения. Было ли это из-за того, что символ 0x42 повторяется так много раз подряд, или из-за того, что это известный символ переполнения для Snort? Что ж, чтобы ответить на наш собственный вопрос, давайте попробуем еще больше запутать сани несколькими другими идемпотентными инструкциями. Остальные мы выберем из списка, который я включил несколькими абзацами выше. Мы будем использовать эти другие, чтобы заполнить наши сани. Наша цель будет заключаться в том, чтобы избежать слишком большого количества повторений подряд.

Теперь, скомпилировав этот новый и улучшенный эксплойт, мы успешно используем его против лабораторной коробки, поскольку снова получаем доступ на системном уровне. Что еще более важно в этом случае, понимает ли Snort, что происходит? Да, действительно, Snort воспринимает это как еще одну попытку переполнения с той же сигнатурой, что и выше. И это несмотря на то, что мы использовали различные функции для восстановления наших саней. Что это оставляет нас тогда? Целью обфускации шеллкода было попытаться обмануть систему обнаружения вторжений, но это не сработало. Реальность такова, что внесенные нами изменения одурачили бы многих аналитиков сетевой безопасности. Я видел некоторых обманутых, потому что они записывали пакеты, которые были зарегистрированы, в результате двоичной передачи.

Как я упоминал ранее, наличие или отсутствие следа NOP не является единственным триггером для сигнатуры переполнения. Существуют и другие факторы, влияющие на создание подписи, такие как порт назначения, подпись ascii или шестнадцатеричная подпись. Возьмем, к примеру, червя Blaster. В качестве эксплойта использовалась уязвимость MS03-026. Одним из ключевых строительных блоков для подписи для него было следующее:

46 00 58 00 4E 00 42 00 46 00 58 00 46 00 58 00 FXNBFXFX

4E 00 42 00 46 00 58 00 46 00 58 00 46 00 58 00 NBFXFXFX

Строка ascii «FXNBFXF X», показанная выше, появляется в фактическом пакете, который выполняет атаку. Это было быстро встроено в сигнатуру и работало достаточно хорошо. Я могу это подтвердить, поскольку в сети, с которой я работаю, до сих пор скомпрометированы ящики, и мы предупреждены об этом с помощью этой сигнатуры.

Инструменты обфускации шелл-кода

Были написаны программы, которые учитывают это и переписывают сам код эксплойта. Это позволяет обойти IDS, так как теперь строка ascii и салазки полностью изменены. Одной из первых программ для этого стала программа ADMutate, написанная К2, канадским исследователем безопасности. Эта программа не для тех, кто плохо знаком с компьютерной безопасностью или кодом эксплойта. Для использования требуется достаточное количество знаний. Другие программы также являются dissembler и asc.c. Они будут делать то же самое, что и ADMutate, но с другой методологией.

это обертка

Проведя тестирование, мы поняли, что современные системы обнаружения вторжений работают достаточно хорошо. Они будут обнаруживать атаки на основе сигнатур, которые есть у самого кода атаки. Если вы попытаетесь изменить различные части кода эксплойта, как это сделали мы, система обнаружения вторжений (IDS) все равно может его обнаружить. Имея это в виду, некоторые исследователи безопасности придумали более новые способы скрытия таких атак, такие как переполнение буфера. Вся моя мысль или тема при написании этой серии статей состоит в том, чтобы сделать акцент на правильном обучении. Очень важно пройти обучение, чтобы вы могли идентифицировать угрозы, когда вы их видите. В противном случае вы можете попробовать поиграть с этими типами инструментов в своей домашней лаборатории, чтобы поддерживать свои навыки в актуальном состоянии. Ландшафт угроз компьютерной безопасности постоянно меняется, и вы должны стараться не отставать от него. Я искренне надеюсь, что вы нашли эту статью полезной, и если у вас есть какие-либо вопросы, пожалуйста, не стесняйтесь обращаться ко мне.