Затемненный Shellcode, Волк в овечьей шкуре (Часть 3)

В этой последней части серии из трех статей о затемненном Shellcode мы заменим хорошо известный след-массив NOP на одну из других инструкций. Мы также увидим, какие изменения обнаружит Snort, если это произойдет.

Если вы пропустили остальные статьи этой серии, пожалуйста, прочтите:

• Затемненный Shellcode, Волк в овечьей шкуре (Часть 1)
• Затемненный Shellcode, Волк в овечьей шкуре (Часть 2)

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

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

/* bindshell no RPC crash, defineable spawn port */
«\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90»
«\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90»
«\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90»
«\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90»
«\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90»
«\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90»
«\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90»
«\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90»
«\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90»
«\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90»
«\x90\x90\x90\x90\x90\x90\x90\xeb\x19\x5e\x31\xc9\x81\xe9\x89\xff»

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

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

/* bindshell no RPC crash, defineable spawn port */
«\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42»
«\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42»
«\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42»
«\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42»
«\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42»
«\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42»
«\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42»
«\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42»
«\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42»
«\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42»
«\x42\x42\x42\x42\x42\x42\x42\xeb\x19\x5e\x31\xc9\x81\xe9\x89\xff»

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

[**] [1:2351:8] NETBIOS DCERPC ISystemActivator path overflow attempt little endian [**]

[Classification: Attempted Administrator Privilege Gain] [Priority: 1]

01/28-11:15:21.861046 192.168.1.102:1045 -> 192.168.1.101:135
TCP TTL:64 TOS:0x0 IpLen:20 DgmLen:1500 DF
***A**** Seq: 0xB498EE5  Ack: 0x7B4CD8CA  Win: 0x5B4  TcpLen: 32
TCP Options (3) => NOP NOP TS: 12684682 1849

[Xref => http://cgi.nessus.org/plugins/dump.php3?id=11808][Xref => http://www.microsoft.com/technet/security/bulletin/MS03-026.mspx][Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=2003-0352][Xref => http://www.securityfocus.com/bid/8205]

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

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

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

46 00 58 00 4E 00 42 00 46 00 58 00 46 00 58 00 F.X.N.B.F.X.F.X.

4E 00 42 00 46 00 58 00 46 00 58 00 46 00 58 00 N.B.F.X.F.X.F.X.

ASCII строка “F X N B F X F X”, видимая выше, — это тот пакет, который подготавливает атаку. Эта строка была добавлена в сигнатуру, и выполнялась вполне нормально. Я могу засвидетельствовать, что, имея в сети, с которой я работаю, уязвимые компьютеры, мы были оповещены об атаке на них этой сигнатурой.

Утилиты для затемнения Shellcode

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

Заключение

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

Источник www.windowsecurity.com

• Планировщик заданий Windows server 2008
• Посмотреть фрагментацию таблиц ms sql
• Как создать контакт в active directori?
• Принт сервер на Windows server
• Нстройка впн server 2008

Tags: bind, cgi, mac, quote, redirect, virus