Эксплойт

Удаленное выполнение произвольного кода в Carberp Web Panel C2

В конце июня случился переломный момент в современном вирусописании. Если раньше у большинства людей были только исходники трояна Zeus, то теперь в публичный доступ утекли исходники банковского трояна Carberp вместе с буткит-фреймворком и административной панелью. Один из популярных исследователей вредоносных программ Xylitol решил провести аудит исходного кода последней и сразу же нашел вот такой код:

Как видишь, если пришел специальный POST-запрос с ключом в параметре , то скрипт выполнит любой код, зашифрованный с помощью алгоритма BASE64 и переданный в параметре .

EXPLOIT

В качестве эксплойта можно воспользоваться следующими наработками:

• Скрипт от автора можно скачать с его блога. Сделан по принципу «нажать кнопку», нужно только ввести адрес предполагаемой административной панели.
• Выпущен Metasploit-модуль.

Или самому в соответствующей программе, скрипте или плагине для браузера составить POST-запрос. Например, на языке PHP это будет выглядеть так:

Пример успешной атаки на одну из административных панелей трояна Carberp

TARGETS

Все версии, установленные до 28 июня. Плюс те, которые будут использоваться вместе с опубликованными исходниками :).

SOLUTION

Патча на данный момент не существует. В качестве быстрого патча можно заменить ключ на любой другой.

Ошибка вызвана некорректной обработкой данных RDATA внутри DNS-запроса. Удаленный пользователь может с помощью специально сформированного DNS-запроса спровоцировать вызов REQUIRE-исключения и аварийно завершить работу процесса named. Уязвимости подвержены как рекурсивные, так и авторитативные DNS-серверы. Причем ограничение доступа с помощью встроенных ACL не позволяет защититься от проблемы. На момент публикации уязвимость (CVE-2013-4854) исправлена в версиях BIND 9.9.3-P2 и 9.8.5-P2, все остальные версии BIND 9, новее ветки 9.6, уязвимы.

Linux/Chapro (Darkleech)

Самый популярный в мире Apachе-бэкдор. Появился в середине 2012 года. Обнаружить его деятельность на сервере затруднительно, так как он не оставляет следов на жестком диске (работает с Shared Memory) и в логах сервера (имеет систему скрытия HTTP-запросов).

Бинарный файл зашифрован с помощью стандартного XOR-алгоритма. Пересылаются похищенные данные POST-запросом по HTTP-протоколу. Передаваемая информация шифруется дважды: с использованием 1024-битного ключа RSA и Base64.

Также в Linux/Chapro есть система сверки IP жертв с базой адресов уже обработанных компьютеров. Страница с вредоносным iframe показывается отдельному пользователю только один раз.

Также вирус умеет подавлять свою деятельность в старых версиях браузеров, в которых iframe-инъекция может сильно бросаться в глаза.

Распространение

Распространяется под видом Apache-модуля Darkleech. Также может быть внедрен с помощью трояна Gootkit (эксплуатируя уязвимость CVE-2012-1823 в PHP-CGI).

Вредоносная деятельность

После заражения сервера вирус внедряет iframe, перенаправляющий на ресурс с Blackhole Exploit Kit, в код страниц сайта. При наличии у пользователя уязвимостей в браузере или плагинах к нему происходит следующее:

Загружается программа Pony Loader, предназначенная для хищения конфиденциальных данных пользователя. Последние версии этой малвари могут украсть даже информацию о логинах и паролях для кошельков с криптовалютами.

Устанавливается троян из семейства Sirefef, который может блокировать брандмауэры, загружать из интернета обновления вирусов, перенаправлять трафик, подделывать поисковую выдачу и многое другое. Конкретный функционал зависит от модификации вируса.

Запускается троян Nymaim, и компьютер блокируется, требуя заплатить штраф суммой в три сотни баксов.

Некоторые модификации Linux/Chapro заражают пользователей трояном Zeus (через эксплойт Sweet Orange), который ворует данные для входа в онлайн-банкинги и другие платежные системы (аналогично поступает бэкдор Linux/Snasko).

Переполнение буфера в версиях Wireshark ниже 1.8.12/1.10.5

BRIEF

Следующая программа также знакома большинству читателей — Wireshark. Без нее анализ сетевого трафика уже многим непривычен и неудобен.

Ошибка обнаружилась в функции из файла , которая используется для парсинга файлов формата MPEG. Сама же уязвимость проявляется из-за отсутствия проверки размера полученных данных, вследствие чего получаем обычное переполнение буфера.

Проблему разработчики легко исправили, добавив проверку на размер пакета:

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

EXPLOIT

Структура файла-эксплойта включает несколько частей:

• сигнатуру (Magic number) MPEG-файла — ;
• случайные данные;
• ROP-цепочку;
• шелл-код;
• случайные данные, число которых определяется размером предыдущих секций;
• инструкцию для обхода SEH-механизма, если файл открывается через командную строку;
• снова случайные данные;
• инструкцию для обхода SEH, если открывается через GUI.

Несколько инструкций SEH пришлось использовать из-за различных сценариев открытия файла. Если интересно, можешь посмотреть историю разработки на GitHub-аккаунте автора.

Чтобы найти ROP-цепочку и инструкции для обхода SEH, как и в предыдущем эксплойте, воспользуемся утилитой . Кстати, команда Corelan в своем видео по использованию скрипта для примера как раз использует одну из уязвимостей в программе Wireshark. В нашем случае, зная нужные библиотеки, можно заюзать такую команду:

А пока возьмем готовый Metasploit-модуль, который генерирует файл формата PCAP для открытия его уязвимой программой Wireshark:

После этого отправляем файл пользователю атакуемой машины из папки, а у себя запускаем клиент, который будет ожидать коннекта:

Осталось дождаться запуска нашего файла, после чего выполняем любые команды на побежденной машине :).

Есть идея попробовать доработать эксплойт, чтобы он генерировал не файл, а пакет, и отправлять его постоянно по сети. Тем самым с большой вероятностью любой человек, который попробует поснифать твои пакеты, используя уязвимую версию, выполнит произвольный код на своей машине. Ну или просто его Wireshark будет постоянно закрываться.

Видео по работе с этой уязвимостью и идеи ее использования опубликовали ребята из Digital Security в своей статье по «побегу» из виртуальной машины.

Генерируем эксплойт-файл для Wireshark в Metasploit

Исполнение произвольного кода в VLC MEDIA PLAYER

9.3 (AV:N/AC:M/Au:N/C:C/I:C/A:C)

Brief

Уязвимость была найдена небезызвестным Рикардо Нарваха, автором эпического руководства «Введение в крекинг с нуля, используя OllyDbg», в VLC Media Player при обработке файловых форматов AMV и NSV. Она эксплуатируется удаленно и приводит к выполнению произвольного кода с привилегиями текущего пользователя. Техника Dangling Pointer, с помощью которой эксплуатируется бага, была описана в далеком 2007 году на конференции Black Hat USA (whitepaper доступна на их сайте). Сама ошибка возникает в библиотеке libdirectx_plugin.dll при обработке 0x41-байта, если его значение больше 90. Эту библиотеку использует Internet Explorer при обработке видео формата AMV, поэтому для успешной эксплуатации достаточно зайти на специально сформированную страничку через бажный IE.

Exploit

С 26 марта эксплойт доступен в Metasploit Framework по адресу exploit/windows/browser/vlc_amv. Для его подготовки и запуска проделываем стандартные шаги:

Запускаем шайтан-машину!

exploit

Напоминаю, что доступные опции можно просмотреть командой show options, полезные нагрузки — show payloads, а доступные целевые системы — show targets. Так же полезно пользоваться автодополнением, которое вызывается клавишей табуляции. После команды exploit на локальной машине запустится веб-сервер и будет дана ссылка неприметного вида, которую и нужно впарить жертве.

Targets

VLC Media Player

Кроме того, для успешной отработки эксплоита из Metasploit Framework у жертвы должна быть одна из следующих конфигураций:

• Windows XP SP3 + IE6;
• Windows XP SP3 + IE7;
• Windows Vista + IE7.

Solution

В конце марта стала доступна обновленная версия плеера 1.1.8, рекомендуется установка данной или более поздней версии.

Ошибка в обработке HTTP-запроса в Windows (HTTP.sys)

BRIEF

Архитектура IIS

В качестве тестовой среды автор использует Windows 8.1 x86 и IIS (Internet Information Service) 8.5. После установки IIS (примерная архитектура представлена на одном из скриншотов) в систему у нас появляется соответствующий сервис с именем World Wide Web Publishing Service (для удобства сократим до WWW). Когда клиент отправляет запрос HTTP к нашей системе, запускается WWW или выбирается рабочий процесс (). Тот использует для различных задач, связанных с обработкой протокола HTTP, и, помимо обычного парсинга запроса, включает в себя и функцию создания ответа, а также кеширование содержимого. В свою очередь, получает HTTP-запросы и отправляет HTTP-ответы с помощью .

Как же мы можем совершить DoS-атаку на нужный нам сервер?

После установки указанного выше ПО у нас появится стартовая страница (размер файла 694 байта). Наш запрос будет следующим:

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score!
Подробнее

Вариант 2. Открой один материал

Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя!
Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.

Я уже участник «Xakep.ru»

Поехали!

Здесь все довольно примитивно — пустая HTML-страница, с которой выполняется переадресация посредством ‘location.href=’. А затем начинается самое интересное — пользовательский браузер загрузит основную страницу BlackHole, с которой будет организовываться выполнение всех остальных эксплойтов. Первым делом я открыл файл в Hiew. Что же я обнаружил? В самом начале, после тэгов <html> и <body>, идет описание свойств стиля ‘asd’:

Далее в div’е с этим стилем расположены какие-то (по-видимому, зашифрованные) данные. Как раз для того, чтобы пользователь не увидел их на экране, и применяется специально подготовленный стиль, прячущий от глаз все лишнее. А заканчивается документ кодом на JS, который слегка обфусцирован и, очевидно, должен работать с информацией в контейнере <div>.

Пора приступать к разбору непосредственно кода. Я отлаживал скрипт с помощью плагина FireBug для FireFox, попутно используя MSDN, чтобы понять назначение некоторых методов и свойств.

Что и как здесь работает, я объясню с конца. Суть всего скрипта — выполнить eval над данными, расположенными в <div>. Но, как видно из скриншота, там расположены какие-то числа, причем не только целые, а еще и вещественные (v*1,22222). Таким образом, к этим числам нужно применить метод fromCharCode, который преобразовывает число в ANSI-символ.

Это и происходит в коде, расположенном на предпоследней строке. Однако не все так просто — строки eval и fromCharCode получаются путем использования хитрых манипуляций. А именно — к объекту document добавляется стиль, к которому в поле innerHTML прибавляется строка #va {background:url(data:,ring.from4harCo)}. Далее из этой строки дергаются символы va для сборки eval и ring.from4CharCo для сборки fromCharCode. Что же получается на выходе после eval’а? А как раз тот документ, который и будет непосредственно запускать эксплойты.

Я сохранил вывод после eval’а в отдельный файл и приступил к его анализу. Файл начинается со следующей строки:

Таким образом, на страницу выводится классическое сообщение об ошибке 404, хотя со страницей, очевидно, все в порядке. Это еще одна уловка, чтобы пользователь ничего не заподозрил. На первый взгляд, кода в html’ке оказалось достаточно много, однако обфускация практически отсутствовала, а большую его часть занимали разнообразные проверки версий плагинов и создание объектов.

Запуск эксплойтов тривиален, поэтому эту часть я решил опустить и перейти непосредственно к описанию каждого из них. Для начала приведу список уязвимостей, которые эксплуатируются: CVE-2010-1885, CVE-2010-4452, CVE-2010-3552, ADODB.Stream и CVE-2010-0188. Начну с самого простого.

CVE-2010-1885

Первый подопытный — VBS-скрипт, эксплуатирующий уязвимость в ADODB.Stream, исправленную еще в середине 2004 (!) года.

Выполнен он типично для такого рода скриптов — слегка обфусцирован и не более того. Например, часть строк была подвержена реверсу. Его функционал заключается в загрузке и запуске файлов из интернета. Но как тебе известно из системных сообщений, файлы из интернета могут быть не только полезны, но и опасны :).

Для реализации описанного функционала используются объекты MSXML2.XMLHTTP, ADODB.Stream и Wscript. Любопытно, что эта уязвимость стара как мир, но до сих пор используется.

CVE-2010-4452

Следующий исследуемый образец — эксплойт, использующий CVE2010-4452. Эта уязвимость была официально опубликована Oracle в середине февраля этого года. С ее помощью можно загрузить Javaапплет и исполнить его в обход системы безопасности. Для этого нужно заполнить поля code и codebase тэга <applet> специальным образом. Одна из особенностей этого эксплойта заключается в том, что адрес, по которому производится загрузка, представляет собой двойное слово в десятичной системе исчисления. Поясню: браузер переведет это число в IP-адрес автоматически. То есть, если перейти по адресу http://1476066051, то браузер успешно откроет страницу популярного российского поисковика.

CVE-2010-3552

Следующий эксплойт, удостоенный чести быть разобранным, использует уязвимость CVE-2010-3552. Дыра опять-таки расположена в Java Runtime Environment. Эксплуатируется она элементарно — если Java-апплет запускается с параметром launchjnlp, то загрузчик копирует строку из поля docbase в стэковый буфер при помощи функции sprintf. Думаю, что дальше пояснять не нужно. Шелл-код также не представляет особенного интереса — вначале идет стандартное получение kernel32 через PEB:

Далее происходит получение адресов API-функций по их хэшам. Завершающий этап — скачивание файла из urlmon.dll при помощи URLDownloadToFile, и затем — его запуск.

Эксплойт для Help and Support Center

На подходе следующий эксплойт, который использует уязвимость в весьма экзотическом компоненте OC Windows — Help and Support Center. Фишка в том, что для доступа к онлайн-ресурсам этот компонент использует специальный адрес, начинающийся с hcp://. А теперь о самом эксплойте — он основан на технике сокрытия кода, аналогичной той, что использует первичная html’ка, которая разбиралась в самом начале. Здесь так же, как и там, используется тэг <div> в качестве контейнера данных.

Обфускация тоже применена аналогичная. Итак, быстро расшифровав «первый слой», я увидел непосредственно эксплойт, использующий CVE-2010-1885.

Первое, что бросилось в глаза — адрес, начинающийся с hcp:// и обилие повторяющихся символов %A. А второе — разнообразные строки, отвечающие за скачивание и запуск файла: SaveToFile, GET, Adodb.Stream, WshShell.Run, MSXML2.XMLHTTP и так далее. Там же находятся ссылка на скачиваемый файл и его локальное название на жестком диске. Таким образом, суть и этого эксплойта сводится к тому, чтобы просто скачать и запустить файл.

SQL инъекция в JOOMLA! COM_VIRTUEMART

7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)

Exploit

Обратимся к скрипту ‘com_virtuemart/classes/ps_module.php’ и рассмотрим функцию get_dir(), которая занимает строчки 255-270:

Обрати внимание на строку, в которой формируется запрос. Переменная $basename поступает туда без всякой фильтрации

Пользователь, в свою очередь, может влиять на еe содержание через GET-параметр page, что можно увидеть в скрипте ‘com_virtuemart/virtuemart_parser.php’, строки 189-210:

В последней строке вызывается функция checkModulePermissions() из скрипта ‘com_virtuemart/classes/ps_module.php’ с интересующим нас параметром page. В ней и происходит вызов уязвимой get_dir(), рассмотренной выше:

Эксплуатация этой уязвимости осложняется двумя вещами:

1. Не выдается ошибка, если запрос неправильный (инъекция слепая).
2. Joomla сама по себе фильтрует символы ‘<‘ и ‘>’ в запросах, поэтому при эксплуатации мы можем использовать только ‘=’ в процессе перебора символов. Это существенно повышает количество оказавшихся в логах запросов к целевому серверу.

Так как по содержанию страницы мы не можем понять, выполнился наш запрос или нет, то остается использовать технику временных задержек при проведении инъекции. Например, если мы имеем дело с MySQL 5 версии, то при таком запросе последует задержка примерно в 30-60 секунд:

В этом запросе используется классическая для техники временных задержек функция benchmark(count, expr), которая выполняет заданное количество раз (count) функцию, указанную во втором аргументе (в данном случае вычисляется хеш MD5 от буковки ‘x’). Эта функция выполняется только в том случае, если выражение ‘substring(@@version,1,1)=5’ истинно. Несложно догадаться, что это выражение сравнивает первый символ переменной @@version с 5. Если на сервере используется MySQL 4-й ветки, то в этом можно убедиться, подставив 4 вместо 5. Если после этого сервер будет тупить целую минуту — значит, наши предположения верны. Эксплойт к этой баге доступен здесь:

Синтаксис:

Пример использования:

В эксплойте предусмотрено использование прокси-сервера, за это отвечает параметр ‘-p’, после которого следует указать реквизиты сервера в формате «хост:порт».

По опыту использования могу сказать, что иногда в процессе его работы возникают ложные положительные срабатывания. Они могут происходить из-за перебоев в соединении с интернетом, прокси-сервером или связи с целевым веб-сервером. Так что если в версии БД или хеше админа появляются разные спецсимволы или недопустимые буквы, то это повод прогнать эксплойт ещe раз. Кроме того, процесс работы эксплойта весьма неспешный, в среднем на извлечение инфы уходит около часа, так что одной чашкой кофе, как предлагает автор эксплойта mr_me, тут не отделаешься. Для экономии времени можно закомментировать ненужные циклы подбора в функции doBlindSqlInjection(). Например, чтобы не извлекать лишний раз информацию о БД, а сразу приступить к хешу админа, нужно закомментировать строчки 163-176.

Joomla! com_virtuemart

Обнови com_virtuemart до версии 1.1.8 либо поставь патч под номером 1.1.7а.

Blackhole Exploit Kit

Набор drive-by эксплойтов, эксплуатирующих уязвимости в Java Virtual Machine и других браузерных дополнениях. Некоторое время (2010–2011 годы) был одним из самых коммерчески успешных хакерских проектов, пока его исходный код не утек в открытый доступ. Включает в себя бесчисленное множество компонентов, среди которых:

TDS (traffic direction script) — скрипт для перенаправления трафика;

Carberp — троян, в частности собирающий данные о зараженной системе;

stopav.plug — система противодействия антивирусам;

passw.plug — система мониторинга посещенных страниц и вводимых логинов/паролей.

Используется для внедрения троянов Zeus, SpyEye и многих других.

Выполнение произвольного кода в Apple Safari

N/A

Apple Safari

BRIEF

Начнем наш обзор с 0day уязвимости в браузере Safari. Уязвимость обнаружил Кристиан Клосковски (Krystian Kloskowski) и незамедлительно опубликовал эксплойт для последней версии яблочного браузера. Ответных действий от Apple в виде патча пока не последовало.

EXPLOIT

Эксплойт представляет собой обыкновенный HTML-файл c JavaScript-кодом. Уязвимость кроется в методе parent.close(), который способен повредить память процесса, что, в итоге, может передать управление злобному шелл-коду. В примере Кристиана – шелл-код запускает калькулятор, но ты же понимаешь, что заменить шелл-код – дело пустяковое. Чтобы эксплойт работал удаленно, необходимо существование родительского объекта. Для этого в эксплойте предлагается первоначально использовать метод window.open(), который откроет HTML с эксплойтом. А для этого нужно, чтобы у жертвы были разрешены всплывающие окна.

Фишка же самого эксплойта в том, что происходит вызов метода close() для родительского объекта, а затем вызов метода prompt() для того же объекта. Так как parent-объект уже «закрыт», у Safari возникает «разрыв шаблона», то есть ошибка в памяти, в результате которой, при обработке метода prompt(), происходит перезапись регистра ESI значением, которое будет браться из ошибочного места. После записи регистра идет вызов по адресу из этого регистра – CALL ESI. Кристиан в своем эксплойте использует до вызова close() еще пару вызовов prompt(), чтобы «сдвинуть» указатель ESI для принятия значения 0x40E00000. Осталось подготовить шелл-код, чтобы он разместился по адресу 0x40E00000. Тут вступает в дело классический heap spray, что приводит к заполнению адресного пространства процесса, включая адрес 0x40E00000, нашим шелл-кодом. Таким образом, жертва открывает страничку, видит окошко, сгенерированное методом prompt(), пытается закрыть его по ALT+F4, видит второе окошко, которое опять закрывает и в результате – pwned после close() и уже не отобразившего окошка, третьего вызова prompt().

Рассмотрим код эксплойта:

Недостаток эксплойта в том, что Safari у нас работает в режиме permanent-DEP, и шеллкод из кучи исполняться не будет. Компания VUPEN разработала коммерческий эксплойт, который обходит permanent-DEP. Ну, мы же кул-хацкеры – сделаем так, чтобы он еще, кроме DEP, и ASLR обходил. Я не знаю, как сделали ребята из компании VUPEN (догадываюсь, что с помощью ROP), но для ASLR этого мало (в данном случае), поэтому я воспользуюсь техникой JIT-SPRAY и одним из шеллкодов, который я же и разработал (себя не похвалишь – никто не похвалит :)). Мой шеллкод открывает блокнот.

Итак, суть проста – заменяем heap spray (который, кстати, жестко палится антивирусами) на JIT-SPRAY. Но не все так легко, как казалось. Если вставить флеш-объект на ту же страницу или даже на родительскую, то при вызове parent.close() вся память, выделенная для Flash, очистится. Тогда я придумал углубить цепочку «наследования». Первая страница грузит JIT-SPRAY и делает открытие в новом окошке второй, вторая страница ничего не делает, кроме как открывает третью. А уже третья страница открывает четвертую – с эксплойтом, но без heap spray. Все страницы в Safari – обрабатывает один процесс, так что память общая. Но адрес 0x40E00000 меня также не устраивает, кто читал мою статью про JIT SPRAY в апрельском ][, тот помнит, что нам нужен адрес вида 0xXXYY0101, чтобы попасть в JIT-шеллкод. Немного побаловавшись с параметром, я нашел ситуацию, когда указатель ESI переписывается значением, генерируемым в качестве параметра метода parent().

Теперь мы можем передать управление по точному адресу. Я выбрал 0x09430101. Там как раз наш шеллкод. Вот и все.

Убить наповал!

Сервер работает ровно до тех пор, пока ему не придет строка, состоящая более
чем из 500 символов. В противном случае – непременно вылет приложения. Набросаем
небольшой скриптик на Perl’е для эксплуатации переполнения буфера:

# адрес и порт узявимого демона
my $host = shift || ‘localhost’;
my $port = shift || 200;
my $proto = getprotobyname(‘tcp’);

# осуществляем привязки
my $iaddr = inet_aton($host);
my $paddr = sockaddr_in($port, $iaddr);

print » Setting up socket\n»;
# создаем сокет и присоединяемся к порту
socket(SOCKET, PF_INET, SOCK_STREAM, $proto) or die «socket: $!»;
print » Connecting to $host on port $port\n»;
connect(SOCKET, $paddr) or die «connect: $!»;

print » Sending payload\n»;
print SOCKET $junk.»\n»;

print » Payload sent\n»;

close SOCKET or die «close: $!»;

Скрипт просто соединяется с сервером и посылает ему строку символов «А»
длиной 1000 ($junk = «\x41» x1000). Чтобы наглядно посмотреть, что в момент
получения такой строки происходит внутри нашего сервера, запускаем его под
отладчиком – идеально, под
OllyDbg. Выбираем наш бинарник через меню «File -> Open» и отдаем команду на
выполнение: «Debug -> Restart -> Run». Далее запускаем простенький сплоит,
который, как и следовало ожидать, убивает наш сервер наповал. Смотрим в отладчик
— адрес возврата из функции pf (и, как следствие, регистр EIP, указывающий на
следующую инструкцию) оказывается перезаписанным значением 41414141 (как ты
помнишь, 0х41 — это символ А). Но на момент, когда мы будем глядеть в отладчик,
уже произойдет возврат по адресу 41414141, и мы будем видеть только EIP. Для
успешной эксплуатации уязвимости нужно построить ядовитую строку так, чтобы она
переписывала адрес возврата нужным нам значением — адресом нашего шелл-кода.
Поэтому сначала необходимо выяснить, какие именно символы строки затирают адрес
возврата. В этом поможет одна из утилит Metasploit Framework. Но перед этим
предлагаю тебе быстренько ознакомиться с Фреймворком.

Заключение

Капитан Очевидность из своей суфлерской будки подсказывает мне, что с течением времени уязвимостей и эксплойт-паков меньше не становится. Поэтому, подводя итог, можно сделать несколько выводов:

• авторы большинства эксплойт-паков от прямой продажи перешли к аренде на своих серверах, при этом зачастую они предоставляют полный цикл услуг — от чистки до постоянной смены доменных имен и проверок на обнаружение антивирусами;
• почти во всех эксплойт-паках стали очень активно эксплуатироваться уязвимости Java и Silverlight;
• многие эксплойт-паки стали обзаводиться функциями распознавания наличия виртуальных машин, антивирусов и разных хакерских утилит;
• уязвимость CVE 2013-2551 пользуется большой популярностью и используется во всех наборах эксплойтов из нашего обзора.