Csploit

Содержание:

API Usage

Our service takes advantage of numerous APIs in order to stay functional. Perhaps in the future we will provide an API of our own for services who want to ensure their client’s browsers are safe for their own service. That decision will be decided later on in 2018.

Here’s a list of all the APIs that we currently use, and the data we send to these services in order to get accurate results.

  • GetIPIntel.net for Proxy / VPN / Bad IP detection | (Data sent: IP address)
  • Check.Torproject.org for Tor Exit Node detection | (Data sent: IP address)
  • IPinfo.io for Hostname and Geolocation data | (Data sent: IP address)
  • Maps.Google.com for displaying location | (Data sent: IP and GPS coordinates)

If you do not wish to have your data sent to these data providers for the sole purpose of serving you accurate test results, please do not use our services.

Privacy policy

By using our service and accessing this site you agree to the conditions specified here and our . «We», «Our», «Us» all refer to the webmasters of this site, SPUZ. «User», «You», «Visitor» all refer to the person(s) agreeing to these conditions and the person(s) accessing our site.

When you run our scripts against your browser, computer system, and network, our system begins collecting and analyzing the data from numerous locations specified in the end test results. After the results have been computed, we do NOT collect any information from those results with the exception of access logs. Access logs contain the time, IP address, and user agent string. This is something that is practical on all webservers.

For clarity, we do NOT collect any data from the test results. In order to supply you with the most accurate test results, we use external, third-party APIs to obtain key pieces of information about your system environment. These external services may collect data such as your IP address. We do not supply any of these third-party API systems with your information with the intent of abuse or profit. We ONLY use them to obtain the necessary data for accurate test results.

An example of one (but not all) APIs that we utilize is TorProject’s exit node list to cross reference whether or not the user is communicating to this server through Tor. We respect your privacy and appreciate your understanding that Sploit, in order to work properly, requires these methods of transmitting and analyzing data.

In order to reduce API costs, we store the data to every API response from all our . The data stored will have a 12 hour expiration time stamp, during that time, any additional request made, our system will fetch the requested data from our own servers. This will reduce any unnecessary API calls that request the same exact data for more than once each 12 hour duration.

Эксплоит за 5 минут

Как видишь, разработать эксплоит для Metasplot не так сложно. Скорее даже
наоборот, ведь большая часть работы уже сделана за тебя. Взять хотя бы огромную
базу шелл-кодов – попробуй разработать свой. Но лени человеческой нет предела,
поэтому в стремлении еще больше упростить процесс был разработан пакет утилит
тебе MSF eXploit Builder. Программа имеет удобный графический интерфейс и
поможет по-настоящему быстро создавать новый модуль для Metasploit. Кроме
удобного GUI, eXploit Builder включает в себя целую кучу полезных тулз,
необходимых для отладки и тестирования эксплоитов. Более того – можно опять же
создавать с нуля, а портировать уже существующие сплоиты.

Предлагаю взять какой-нибудь эксплоит и с помощью MSF eXploit Builder
превратить его в Metasploit-модуль. Ты спросишь, зачем это нам надо? Опять же:
превратив его в Metasploit-модуль, мы можем использовать его вместе с различными
payload-ами. Проще говоря, это сделает его более универсальным и
кроссплатформенным. Сейчас ты сам убедишься, насколько эта программа может
упростить жизнь — ведь теперь для написания и отладки эксплоита не нужно даже
знание Ruby и Metasploit API. В качестве кролика для эксперимента я выбрал
первое, что попалось, — сплоит для tftpdwin 0.42 (milw0rm.com/exploits/7452).

Запускаем MSF eXploit Builder, заходим в меню «Editor» и выбираем «New».
Появляется окно с несколькими вкладками (Information, Badchars, Analysis,
Shellcode, Design). Переходим на вкладку «Information» и видим много интересных
полей. Как ты помнишь, в этой секции указываются цели (OS + SP) и тип/протокол
эксплоита (например, remote/tcp). Более того, программа предоставляет нам
возможность тестирования и отладки полученного эксплоита, поэтому тут же можно
выбрать исполняемый файл и указать параметры для его запуска (порт, ip-адрес).

Итак, выбираем наш tftpd.exe, после чего утилита предложит следующие действия
на выбор: запустить приложение, запустить его под отладчиком или не запускать
вообще – просто запустим приложение

Обрати внимание, что справа сбоку
отобразится список загруженных приложением DDL’ек

Теперь начинаем смотреть код сплоита – на наше счастье он предельно понятный.
Комментарий «Restricted chars = 0x00 0x6e 0x65 0x74» явно указывает на
запрещенные символы – что ж, выставим их в нашей программе. Для этого переходим
на вкладку Badchars и в одноименном поле вводим: \x00\x6e\x65\x74. Далее по коду
мы видим, как формируется ядовитый пакет:

Разбираемся с каждой составляющей и заодно составляем буфер для отправки во
вкладке «Design». Сначала идет переменная $p1 (my $p1=»\x00\x01″;). Вводим их в
поле Value (Operation по умолчанию оставляем RAW). За ней идет переменная $nopsled
(my $nopsled = «\x90» x 10;) — выбираем Operation = NOP и устанавливаем длину в
10. Далее располагается $shellcode — устанавливаем Operation = PAYLOAD и Length
= 0. Следующая часть — $overflow (my $overflow = “\x41” x $len; строка из
символов «А» длиной в $len). Переменная my $len = (274 — length($shellcode)), то
есть строка длиной 274 символа минус длина шелл-кода. Выставляем Operation = RAW,
Length = 274 и выбираем (нажимаем поочередно) вверху кнопки RAW could be:
rand_text_alpha, -payload.encoded.length, что означает: длина строки будет
высчитываться по вышеприведенной формуле. Потом добавляем адрес возврата $ret (my
$ret = “\x5d\x10\x40”) и выбираем Operation = RET. Наконец, добавляем $p2,
равное «\x00\x6e\x65\x74\x61\x73\x63\x69\x69\x00» и выбираем Operation = RAW.
Ядовитый пакет готов.

Собственно, теперь у нас есть все для создания готового сплоита. Поэтому
нажимаем на кнопку «Generate» и любуемся кодом получившегося сплоита. Если
какие-то моменты вызывают сомнения, тут же можно отредактировать код вручную.
Классно, что возможно сразу проверить работоспособность кода – для этого смело
жмем кнопку «Test». И ведь – все работает! За 5 минут, которые ушли на
ознакомление с программой, и без всякого знания, как языка Ruby, так и структуры
Metasploit, мы создали полностью рабочий сплоит. Это дорогого стоит! В качестве
домашнего задания попробуй с помощью MSF eXploit Builder создать эксплоит для
нашего сервера :).

Эксплоит для Metasploit

Итак, у нас есть сплоит для конкретной платформы с вполне определенной
нагрузкой, открывающей в системе шелл. Так зачем нужна вообще какая-либо
специальная платформа для создания сплоита, если мы вполне обошлись силами
одного лишь Perl’а? Причина в том, что Metasploit предоставляет огромное
количество заготовок, реализаций различных протоколов, одну из самых больших баз
шелл-кодов, payload-ов, которые можно использовать при написании собственного
эксплоита. Вместо убогого скрипта на Perl’е можно написать модуль для Metasploit,
после чего запускать его на любой платформе и выбирать payload на свой вкус!
Чуешь разницу? Предлагаю прямо сейчас усовершенствовать наш сплоит, переписав
его для Metasploit, и посмотреть, как это работает. Само собой, он будет
обладать возможностью выбора платформы для атаки, а выбирать пейлоад ты сможешь
прямо во время исполнения атаки.

Любой эксплоит для Metasploit имеет фиксированную структуру, которая состоит
из объявления заголовочных файлов, подключения ядра msf/core, определения класса
эксплоита, в котором описывается его функциональность. Я не буду приводить здесь
полный исходник модуля, но выкладываю его на диске. Рекомендую для большей
ясности открыть его прямо сейчас и далее читать мое практически построчное
объяснение его кода.
Первое, с чего начинается любой сплоит, – это подключение ядра Metasploit
Framework:

Функциональность любого сплоита описывается с помощью класса, где его
настройки задаются с помощью параметров, а функциональность – с помощью методов.
Создаваемый объект наследуется от одного из предопределенных классов. Поскольку
мы создаем удаленный сплоит, то и наследуем наш объект от родительского класса
«Удаленный эксплоит». В синтаксисе Ruby это делается так:

Большая заслуга Metasploit в том, что он унифицирует большое количество
параметров и действий, позволяя использовать готовые конструкции вновь и вновь.
Первый элемент разрабатываемого класса – секция include, где мы подключаем
обработчик для нужного нам протокола. В Metasploit есть обработчики для http,
ftp и других протоколов, что позволяет быстрее писать эксплоиты, не
заморачиваясь с их собственной реализацией. Наш эксплоит использует
TCP-подключение, поэтому код будет выглядеть следующим образом:

Далее весь сплоит делится на два метода: метод инициализации, в котором мы
указываем информацию, необходимую для успешного выполнения эксплоита, и метод
эксплуатации, в котором мы отправляем на сервер ядовитую строку.

Начнем с инициализации. Параметр Payload задает длину ядовитого буфера и
недопустимые символы (в нашем случае – 0х00 и 0xff):

Далее определяем цели эксплоита и специфичные для каждой цели параметры,
такие как адрес возврата, смещение и т.д.:

Обрати внимание, мы не определяем сам шелл-код – то есть, нагрузку, которую
выполнит сплоит. Действие на удаленной машине будет выбираться интерактивно во
время работы в консоли Metasploit’ом

Сейчас нам остается только написать самое
главное — метод для эксплуатации уязвимости. С помощью команды connect
устанавливаем TCP-соединение (обработчик протокола мы подключили выше и даже
указали порт, помнишь?), далее – определяем ядовитую строку и передаем ее в
сокет, после чего разрываем соединение. Ядовитый буфер состоит из цепочки
NOP-команд, величины Offset — затем к ней прибавляется адрес возврата, еще
небольшая NOP-цепочка и зашифрованный PAYLOAD. Все вместе выглядит так:

junk = make_nops(target)
sploit = junk + .pack(‘V’) + make_nops(50) + payload.encoded
sock.put(sploit)

handler
disconnect
end

Вот и все, наш первый модуль для Metasploit готов! Чтобы его можно было
использовать, скопируем исходник в папку modules/exploits/test (если не нравится
test – можешь скопировать в windows/misc, например). Запускаем msfconsole и
работаем в интерактивной консоли Metasploit’а!

Пишем жертву для экспериментов

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

int main(int argc, char **argv)
{
………………..
int bytesRecv = SOCKET_ERROR;
while( bytesRecv == SOCKET_ERROR )
{
//Получаем данные, отправленные клиентом
bytesRecv = recv( clientSocket, Message, 5000, 0 );

if ( bytesRecv == 0 || bytesRecv == WSAECONNRESET )
{
printf( «\nConnection Closed.\n»);
break;
}
}

pr(Message); // вызываем функцию, которая не проверяет длину входного буфера при
копировании

closesocket(clientSocket);
closesocket(serverSocket);
WSACleanup();
return 0;
}

Внимательно взглянув на код, можно увидеть, что функция void pr(char *str) не
проверяет длину входного буфера и, если передать ей в качестве параметра строку
длиной более 500 символов — получится классическое переполнение буфера. Совсем
кратко о том, как это работает (тут придется вспомнить, как работает стек):

После вызова CALL стек будет выглядеть следующим образом:

….
buf — локальная переменная, куда будем копировать входящие данные
ebp — сохраненный указатель кадра стека
ret — адрес возврата
*str — указатель на входящий буфер
….

Под переменную buf у нас выделено 500 байт. А что будет, если скопировать
туда строку длиннее?

Как видишь, такая строка затрет EBP, адрес возврата и все, что расположено
ниже по стеку – перезапиши адрес возврата нужным нам значением и тогда при
выходе из функции мы можем вернуться, куда захотим, например, на наш шелл-код.

Правда, стоит сделать поправку: уязвимости может и не быть. В смысле, от
такой критической ошибки, конечно, никуда не деться, и программа в любом случае
будет падать, однако использовать переполнение в сплоите может и не получиться.
Виной тому стековые куки – специальная защита, включаемая в бинарник
компилятором во время сборки приложения. Существует несколько способов обхода
такой защиты (подробнее – смотри ниже), но сейчас для простоты примера
предположим, что стековые кукисы отключены. Поэтому либо отключаем поддержку
кукисов во время компиляции в Visual Studio, либо используем компилятор, который
вообще не умеет встраивать подобную защиту. Второй вариант, как мне кажется,
проще – так как можно использовать бесплатный компиляторlccwin32.
Компилируем и запускаем.

Terms and conditions

By using our service and accessing this site you agree to the conditions specified here and our . «We», «Our», «Us» all refer to the webmasters of this site, SPUZ. «User», «You», «Visitor» all refer to the person(s) agreeing to these conditions and the person(s) accessing our site.

We are NOT responsible for any damages or crimes resulted by using our service. Our site runs several scripts against a visitor’s browser in order to alert against vulnerabilities. This process can sometimes alert the user against false positives, the test results may not always be 100% accurate. We are NOT responsible for any damages that may have occurred against a user’s computer system and/or browser by using our service.

By using our site, you FORFEIT any cost(s) of damage which may have occurred at any time while present on this site. Our test results may sometimes give the visitor the opportunity to test against exploits in which the user may be vulnerable to. We audit the exploits to make sure they’re no longer malicious, but in the event in which something goes wrong, we are NOT responsible. The demo exploits on this site are never executed automatically, the visitor must press the button labeled «Execute» in order for them to be executed against the visitor’s machine.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *