Linux htb что это
Разделение, ограничение и управление трафиком - актуальная и сложная задача,
которую обычно возлагают на дорогостоящее специальное сетевое оборудование. Но
решить ее можно и с помощью подсистемы Linux-ядра Traffic Control, не
уступающей по возможностям Cisco IOS.
Допустим, существует офис некой компании X, и в нем числится около ста
сотрудников, каждый из которых может выходить в интернет через шлюз. Скорость
внешнего канала составляет 100 Мбит. Системный администратор справился с
настройкой шлюза в силу своих способностей – что и посчитал достаточным для
правильного функционирования сети. К чему это привело? К увольнению
недальновидного (или ленивого) админа.
Со временем большинство сотрудников начали жаловаться на "тормоза" интернета,
а другие, наоборот, заметили, что могут качать торренты в рабочее время на очень
внушительных скоростях. Говоря админским языком, в сети образовались заторы,
вызванные теми, кто в тот момент активно ее использовал. Стомегабитный канал
распределялся неравномерно между пользователями, и каждый мог занять его весь.
Остальным приходилось ждать.
Краткий сценарий
Решение проблемы: разделение канала между сотрудниками с ограничением
скорости! Сеть будет функционировать на "5+", если каждый сотрудник получит в
распоряжение отдельный канал, скорость которого будет составлять 1 Мбит. Тогда
отдельно взятый интернет-пользователь не сможет занять больше причитающейся ему
доли и отобрать часть канала у других. С точки зрения компании, это еще и
отличный способ экономии (после разделения канала оказывается, что его суммарная
пропускная способность даже излишне высока) и ведения статистики по трафику для
отдельно взятого сотрудника.
Обычно для разделения канала с ограничением скорости используются возможности
операционной системы IOS, на которой функционирует сетевое оборудование Cisco
(дешевые решения от других производителей, таких, как Dlink, Trendnet и Netgear,
вообще не обладают такой возможностью). Однако особой необходимости тратить
баснословные суммы на аппаратные шлюзы от Cisco нет. Ядро Linux уже более пяти
лет как содержит в себе код сложной и весьма функциональной подсистемы
управления трафиком Traffic Control, которая по некоторым параметрам даже
обходит IOS.
Подсистема Traffic Control
Подсистема Traffic Control поддерживает множество методов
классификации, приоритезации, разделения и ограничения трафика (как исходящего,
так и входящего). Она очень гибка в настройке, но сложна в понимании. Поэтому мы
уделим значительную часть статьи теоретическому материалу и лишь затем приступим
к решению задачи с помощью HTB – одной из наиболее гибких и популярных дисциплин
Traffic Control.
Подсистема управления трафиком Linux позволяет делать следующее:
- Shaping. Шейпинг - ограничение трафика, задержка пакетов с
целью создания желаемой скорости передачи. Может использоваться не только для
"сужения" исходящего канала, но и для сглаживания бросков во время пиковых
нагрузок. - Scheduling. Планирование – упорядочивание типов трафика в
канале. Позволяет избегать задержек для критичных типов трафика (QoS). - Policing. Политика входящего трафика. Позволяет ограничить
входящий трафик путем уничтожения превысивших лимит пакетов. Помогает бороться
с DDoS.
Отметим, что ограничение без потерь возможно только в отношении исходящего
трафика. Стек протоколов TCP/IP не предусматривает возможности заставить
удаленную сторону слать пакеты медленнее (и это правильно).
В обработке трафика участвуют три ключевых сущности: дисциплины обработки
пакетов, классы и фильтры. Настройка эффективной системы ограничения трафика
невозможна без понимания механизмов их работы, роли и связи друг с другом. Мы в
подробностях рассмотрим каждую из них:
- Дисциплина обработки пакетов (qdisc) - очередь пакетов и
закрепленный за ней алгоритм обработки. - Класс (class) - логический контейнер, который может
содержать несколько подклассов или дисциплину. - Фильтр (filter) - механизм классификации трафика.
В простейшем варианте путь пакета от приложения до удаленного конца
соединения выглядит так. Приложение генерирует (пользуясь услугами библиотек и
ядра) сетевой пакет и отдает его ядру, которое помещает пакет в очередь FIFO
(первым пришел, первым ушел). Драйвер сетевой карты время от времени обращается
к специальному алгоритму ядра, который извлекает из очереди пакет и отдает его
драйверу. Далее пакет уходит к адресату. Все просто.
Linux действует таким же образом. Но формат представления очереди и алгоритм
ее обработки, в совокупности называемые дисциплиной обработки пакетов, в нем
заменяемы! По умолчанию используется дисциплина pfifo_fast, реализующая очередь
FIFO. Пользуясь утилитой tc, администратор может заменить ее на другую
дисциплину, которая будет переупорядочивать пакеты (планирование), задерживать
их на определенное время (шейпинг) или выполнять другие действия.
Дисциплины классов
Traffic Control не был бы столь гибким, если бы не позволял разбивать
трафик на классы с помощью классовой дисциплины и набора ее подклассов.
Схематически классовая дисциплина очень похожа на файловую систему, c тем лишь
исключением, что ее корень или классы (каталоги) могут содержать либо дисциплину
(файл), либо подклассы (подкаталоги). Одно из двух. Классовые дисциплины и
классы предназначены для построения дерева выбора. Сначала весь трафик
разбивается на несколько общих классов (например, трафик до Отдела-1, трафик до
специализированных внутренних серверов и т.д.), а затем каждый из них
разбивается на несколько подклассов (например, трафик до DNS-сервера Отдела-1),
за которыми уже могут быть закреплены дисциплины.
Чтобы управлять тем, дисциплиной какого класса будет обработан определенный
тип трафика, классовые дисциплины позволяют подключать к себе фильтры. Это дает
возможность "завернуть" определенный трафик в один из ее подклассов. Фильтры
используют классификаторы для идентификации пакетов нужного типа и как бы
говорят ядру: "Этот вид трафика должен обрабатываться с помощью дисциплины вот
этого класса". Существует несколько разных классификаторов. Самыми популярными
являются u32 и fw. Первый позволяет выделять пакеты по исходящим адресам и
адресам назначения, портам, парам "хост:порт", типам протокола и типу сервиса.
Второй классифицирует пакеты путем чтения маркировок, записанных брандмауэром
iptables/netfilter (цель MARK).
За каждым сетевым интерфейсом должны быть закреплены две особые дисциплины:
корневая дисциплина (root qdisc) и входящая дисциплина (ingress qdisc). В первую
помещается весь исходящий трафик (по умолчанию используется дисциплина
pfifo_fast). Во вторую - входящий.
Для идентификации дисциплин и классов используются дескрипторы. Они состоят
из старшего и младшего номеров. Первый - это произвольное число, однако все
классы, имеющие общего родителя, должны иметь одинаковый старший номер. Младший
номер используется либо для произвольной идентификации классов, либо для
указания на то, что объект является дисциплиной (номер 0). Специальный
дескриптор ffff:0 зарезервирован для входящей дисциплины.
Утилита tc
Для конфигурирования подсистемы управления трафиком предназначена утилита tc
из пакета iproute2. Она принимает набор команд в качестве аргументов, с помощью
которых можно создавать классы, привязывать к ним дисциплины и добавлять
фильтры. Синтаксис ее похож на синтаксис команды ipfw из операционной системы
FreeBSD, так что знакомые с ним быстро освоятся.
Для примера рассмотрим простейший вариант использования:
Эта команда устанавливает ограничение для всего исходящего трафика в 256
Кбит/с. Разберем подробнее все аргументы tc:
- qdisc add - добавляем новую дисциплину (для удаления используй del).
- dev eth0 - указываем устройство, к которому будет привязана дисциплина.
- root - наша дисциплина корневая (будет обрабатываться весь трафик).
- tbf - имя дисциплины.
- rate 256kbit latency 50ms burst 1540 - параметры, специфичные для данной
дисциплины: rate - ограничение скорости, latency - максимальный "возраст"
пакета в очереди, burst - размер буфера.
Проще говоря, команда подключает дисциплину tbf в качестве корневой на
интерфейсе eth0 и задает ей несколько параметров. Token Bucket Filter (TBF) -
это бесклассовая дисциплина, которая передает поступающие пакеты с заданной
скоростью.
Способ указания скоростей и других величин в утилите tc несколько отличается
от общепринятого, поэтому следующую табличку придется запомнить:
Формат указания скорости в утилите tc
mbps = 1024 kbps = 1024 * 1024 bps => Байт/с
mbit = 1024 kbit => Кбит/с
mb = 1024 kb = 1024 * 1024 b => Байт
Заменить стандартную корневую дисциплину на любую бесклассовую совсем
несложно, но на таком коне далеко не уедешь. Для создания разветвленной системы
управления трафиком нужны классовые дисциплины, классы, фильтры и целое дерево
дисциплин. Чтобы настроить все это, может понадобиться не один десяток команд.
Мы рассмотрим несколько вводных примеров, перед тем как перейти к обсуждению
дисциплины HTB.
Пример дерева дисциплин
Подключим дисциплину prio в качестве корневой и назначим ей имя (дескриптор)
"1:0":
Результат этой команды: дисциплина prio, подключенная в качестве корня, и три
класса (1:1, 1:2 и 1:3) внутри нее, к каждому из которых подключена дисциплина
FIFO.
Мы вольны заменить любую из дисциплин, подключенных к классам, чем и
воспользуемся для подключения дисциплины sfq с дескриптором "10:0" к классу
"1:1":
Это обеспечит справедливое разделение канала между интерактивными
приложениями (они имеют наивысший приоритет). Чтобы остальные приложения, такие
как менеджеры закачек и torrent-клиенты (которые обычно шлют пакеты с меньшим
приоритетом в поле TOS), не мешали интерактивным, ограничим для них скорость:
Такая схема будет плохо работать в реальной жизни, но для примера вполне
годится.
Теперь сделаем так, чтобы весь SSH-трафик имел наивысший приоритет. Для этого
закрепим за корневой дисциплиной prio фильтр, который будет перенаправлять
пакеты с портом назначения 22 в дисциплину класса "1:1".
Рассмотрим подробнее механизм подключения фильтров.
- filter add - Добавляем фильтр.
- dev eth0 - Указываем устройство.
- parent 1:0 - Дескриптор родителя.
- protocol ip - Протокол, с которым будет работать фильтр.
- prio 1 - Присваиваем классифицированному трафику приоритет 1 (наивысший).
- u32 - Используемый классификатор.
- match ip dport 22 0xffff - Параметры классификатора. В данном случае
указание отбирать пакеты с портом назначения 22. - flowid 1:1 - Отфильтрованные пакеты должны иметь класс "1:1" и
обрабатываться с помощью его дисциплины.
Это все. Мы получили разветвленную систему управления трафиком, выполнив
всего пять команд.
Классовая дисциплина HTB
Еще в первый релиз системы Traffic Control была включена классовая
дисциплина CBQ (Class-Based Queue), предназначенная для реализации сложных
систем управления и ограничения трафика. CBQ завоевала большую популярность
благодаря своей гибкости, но была очень сложна, запутана и обладала рядом
ограничений (тут и необходимость заранее указывать максимальную пропускную
способность канала, и неэффективный алгоритм шейпинга).
Поэтому в скором времени появилась более эффективная и простая в
использовании альтернатива под названием HTB (Hierarchical Token
Bucket). Классовая дисциплина HTB предназначена для разделения полосы
пропускания между различными видами трафика, каждому из которых может быть
предоставлена полоса гарантированной ширины. Она не обладает гибкостью CBQ, но
гораздо более проста в настройке и лишена ее недостатков. Именно на HTB сегодня
принято строить сложные и эффективные системы ограничения трафика.
Рассмотрим применение HTB на примере, представленном в начале статьи, но
более усложненном. Допустим, у нас есть шлюз на Linux, интерфейс eth1 которого
смотрит наружу, а eth0 - во внутреннюю сеть. Ширина канала - 100 Мбит. Задача:
разделить канал между сотрудниками компании так, чтобы директор и сотрудники
IT-отдела могли выходить в интернет без скоростных ограничений, маркетологи
получили ограничение в 2 Мбит/c каждый, менеджеры - 1 Мбит/c, секретари - 512
Кбит/c, а все остальные - 256 Кбит/c.
Есть два варианта решения. Первый: составить огромную таблицу IP-адресов и
создать специальные правила ограничений для каждого адреса (с точки зрения
системы HTB это будет выглядеть как огромный набор классов и фильтров, по одному
на каждый адрес). Второй: разбить всех потребителей канала на мета-группы,
каждую из которых выделить в отдельную подсеть (директор и IT-отдел -
172.16.1.0, маркетологи - 172.16.2.0, менеджеры - 172.16.3.0, секретари -
172.16.4.0, остальные - 172.16.5.0). Для каждой подсети назначить суммарное для
всех ее членов ограничение со справедливым разделением канала.
Мы же создадим симбиоз этих двух систем, когда трафик сначала будет
разбиваться на подклассы, соответствующие подсетям, а уже потом на отдельные
классы для каждого пользователя.
Для начала создадим работоспособную систему, основанную только на втором
варианте решения задачи. Подключим дисциплину HTB в качестве корневой:
Опция "default 15" говорит о том, что весь неклассифицированный фильтрами
трафик должен быть обработан с помощью дисциплин класса "1:15". Создадим
корневой класс, под который будет попадать весь трафик (это нужно для реализации
заимствования):
Создадим в нем пять подклассов для пяти наших подсетей. Директору и IT-отделу
выделим 30-мегабитный канал с возможностью его расширения (заимствования) вплоть
до 100 Мбит в случаях, когда остальные каналы не заняты:
Для маркетологов выделим 20-мегабитный канал:
Менеджерам – 10 Мбит/с:
Секретарям – 5 Мбит/с:
И – 40 Мбит/с на всех остальных:
По умолчанию к вновь созданным классам подключены дисциплины, реализующие
очередь FIFO. Это нам не подходит. Чтобы канал равномерно распределялся между
всеми участниками подсети, мы должны подключить к ним дисциплину sfq:
Теперь подключим фильтры, которые будут классифицировать трафик:
Для "всех остальных" фильтр не нужен, потому как мы уже указали дефолтовый
класс неклассифицированного трафика.
Все, система будет работать, но не обеспечит жесткого ограничения для каждого
пользователя (если, например, в определенный момент времени интернетом будет
пользоваться только один менеджер, ему достанутся все 10 Мбит, отведенные для
всех менеджеров). Жесткое ограничение можно реализовать, если вместо дисциплин
подключить к классам другие классы HTB, по одному на каждого пользователя, и
создать соответствующие фильтры.
Для примера, установим ограничение в 256 Кбит/с для пользователя,
находящегося в подсети "все остальные". Сначала добавим к "классу-подсети" новый
"класс-пользователь":
Подключать к классу дисциплину нет необходимости, так как по умолчанию к нему
уже подключена дисциплина FIFO. Подобные команды придется выполнить в отношении
каждого пользователя, не забывая давать им уникальные дескрипторы класса. При
желании все это нетрудно упаковать в простой скрипт, который будет проходить по
списку IP-адресов и выполнять связку команд для каждого адреса.
Под катом описано как шейпировать трафик в Linux и что для этого нужно знать.
Осуществлять шейпирование трафика будем посредством утилиты tc из пакета iproute2.
Знания без которых нельзя осознать всю полноту управления трафиком в Linux:
Шейпировать можно только исходящий из интерфейса трафик. (в связи с чем возникает проблема с nat, о ней мы поговорим позже). Предположим, что имеется роутер между «интернетом» и абонентом. В роутер воткнуто две сетевые карты: eth0 смотрит на абонента, а eth1 в мир. Для ограничения «скорости скачивания» правила шейпирования описываем на eth0, для ограничения «отдачи» — на eth1.
Необходимо понимать разницу между rate и ceil. Rate — гарантированная полоса пропуская, Ceil — максимальная полоса которую может получить данный класс, rate не может быть больше ceil
Параметры rate и ceil для корневого класса должны совпадать. Таким образом мы определяем общую полосу пропускания.
Сумма Rate'ов классов-потомков, не должна превышать Rate родительского класса. Конечно можно не выполнять этот пункт, но тогда могут возникнуть проблемы с предоставлением «гарантированной полосы пропускания».
Идентификаторы классов указаны в шестнадцатеричной системе, и должны находиться в пределах от 2 до 2^16
Для промежуточных классов необязательно создавать дисциплины и фильтры.
Идентификаторы классов в пределах интерфейса должны быть уникальны.
В простом варианте изложения алгоритм нарезки трафика выглядит так:
1. Создаем корневую дисциплину для интерфейса и указываем класс куда будет попадать не классифицированный трафик.
2. Создаем корневой класс и определяем ширину канала.
3. Создаем дочерний класс для шейпирования абонента.
4. Создаем дисциплину шейпирования для класса абонента.
5. Создаем фильтра позволяющие классифицировать трафик абонента.
Получение htbinit
debian:
Создаем класс для не классифицированного трафика
debian:
Создаем общий клиентский класс. Пускай его ID будет равно «D» и всего для абонентов мы выделим 10 Мбит.
debian:
Теперь можно заняться абонентами.
Что бы ограничить скорость скачивания в 512 КБит абоненту Василию нужно:
Создать класс для абонента Василия. Пускай ID клиентов будут начинаться с 255. Весьма полезно, если потребуется создать какой либо «системный» класс.
debian:
Название файла генерируется таким образом:
1. Интерфейс к которому принадлежит класс.
2. Разделитель "-"(минус)
3. ID корневого класса
4. Разделитель ":"(двоеточие)
5. ID родительского класса
6. Разделитель ":"(двоеточие)
7. ID клиентского класса
8. Разделитель "."(точка)
9. Мнемоническая составляющая названия файла
Пункты 5 и 6 могут отсутствовать, в зависимость от выбранной Вами стратегии шейпирования.
Подключаться к машинам с HTB рекомендуется только через VPN. Не делай этого с компьютеров, где есть важные для тебя данные, так как ты окажешься в общей сети с другими участниками.
Разведка. Сканирование портов
Добавляем IP-адрес машины в / etc/ hosts :
И сканируем порты.
Справка: сканирование портов
Сканирование портов — стандартный первый шаг при любой атаке. Он позволяет атакующему узнать, какие службы на хосте принимают соединение. На основе этой информации выбирается следующий шаг к получению точки входа.
Наиболее известный инструмент для сканирования — это Nmap. Улучшить результаты его работы ты можешь при помощи следующего скрипта.
ports = $( nmap -p- --min-rate = 500 $1 | grep ^[ 0- 9] | cut -d '/ ' -f 1 | tr '\ n' ', ' | sed s/, $/ / )Он действует в два этапа. На первом производится обычное быстрое сканирование, на втором — более тщательное сканирование, с использованием имеющихся скриптов (опция -A ).
Находим три открытых порта: 21 (FTP-сервер vsftpd 3.0.3), 22 (служба SSH 8.2p1) и 80 (веб‑сервер gunicorn).
Справка: брутфорс учеток
Поскольку в начале прохождения у нас нет учетных данных, нет и смысла изучать службы, которые всегда требуют авторизации (например, SSH). Единственное, что мы можем делать здесь, — это перебирать пароли брутфорсом, но у машин с HTB почти всегда есть другое прохождение. В жизни таких вариантов может не быть, к тому же есть шансы подобрать пароль или получить его при помощи социальной инженерии.
Посмотрим, не доступно ли что‑то на FTP анонимным пользователям.
Попытка подключения к FTP как anonymous
Ничего не получилось, поэтому нам нужно «пробивать» веб.
Точка входа. Сканирование веб-контента
Поищем, нет ли чего‑нибудь интересного на сайте. Наша цель — определить вектор дальнейшей атаки, но по дороге нужно собирать и другую информацию: имена пользователей, используемые технологии и прочее.
На сайте нас встречает какая‑то статистика, а также есть следующие страницы:
- Security Snapchat — показывает протоколы и количество сетевых пакетов;
- IP Config — на этой странице отображается информация о сетевых интерфейсах;
- Network Status — показаны конфигурации сети.
Давай перейдем к странице Security Snapchat. Нам предоставлена возможность что‑то скачать, сделаем это.
Скачивание PCAP-файла с Security Snapchat
Открыв файл (я для этого использовал Wireshark), обнаружим, что он пуст. Видимо статистика по сетевым пакетам, которая отображается на странице, собрана именно по этому файлу.
Окно Wireshark
Теперь просканируем содержимое директории / data/ , к примеру с помощью ffuf, которому в качестве параметров нужно передать список для перебора (опция -w ) и URL (опция -u ). Место, куда будут подставляться слова из списка, пометим последовательностью FUZZ . Так как интересны адреса, которые вернут код 200, укажем это в параметре -mc .
Заходя на разные страницы, мы видим число пакетов в том или ином дампе трафика. Так можно определить, что если размер ответа равен 17 144 байтам, то соответствующий дамп будет пуст. Наша теория подтвердилась после того, как мы открыли страницу номер 22, размер которой составляет 17 154 байта. С нее мы можем скачать непустой дамп трафика.
Загрузка файлов в Burp History
Продолжение доступно только участникам
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее
Подключаться к машинам с HTB рекомендуется только через VPN. Не делай этого с компьютеров, где есть важные для тебя данные, так как ты окажешься в общей сети с другими участниками.
Разведка. Сканирование портов
Добавляем IP-адрес машины в / etc/ hosts :
И сканируем порты.
Справка: сканирование портов
Сканирование портов — стандартный первый шаг при любой атаке. Он позволяет атакующему узнать, какие службы на хосте принимают соединение. На основе этой информации выбирается следующий шаг к получению точки входа.
Наиболее известный инструмент для сканирования — это Nmap. Улучшить результаты его работы ты можешь при помощи следующего скрипта.
ports = $( nmap -p- --min-rate = 500 $1 | grep ^[ 0- 9] | cut -d '/ ' -f 1 | tr '\ n' ', ' | sed s/, $/ / )Он действует в два этапа. На первом производится обычное быстрое сканирование, на втором — более тщательное сканирование, с использованием имеющихся скриптов (опция -A ).
Мы нашли много открытых портов, давай пройдемся по порядку:
В итоге мы получаем очень важную информацию. Во‑первых, мы можем работать со службой FTP без авторизации, а во‑вторых, SQL Server дал нам имена домена ( LICORDEBELLOTA ) и текущей машины ( PIVOTAPI ).
Давай скачаем все файлы с FTP-сервера для дальнейшего анализа. Сделаем это с помощью wget :
В документах ничего важного для продвижения не нашлось, но тема интересная — они описывают способы эксплуатации различных уязвимостей. Но, как отмечается в любом курсе OSINT (разведка на основе открытых источников), если мы смогли получить какие‑либо документы, нас могут заинтересовать метаданные, а именно атрибуты «создатель» и «владелец». Из них иногда можно узнать имена, подходящие в качестве логинов. Смотреть эти данные можно разными методами, я воспользуюсь exiftool (устанавливается командой sudo apt install exiftool ).
Свойства документа notes1.pdf
Создав простой конвейер на Bash, получим из всех документов поля Creator и Author .
Откинув сомнительные записи, мы можем составить список из пяти возможных имен пользователей: saif , byron , cairo , Kaorz , alex .
Точка входа. ASRep Roasting
Так как на хосте работает Kerberos, мы можем проверить, существует ли какая‑то учетная запись. В этом нам поможет атака ASRep Roasting. Смысл ее в том, что мы посылаем на сервер аутентификации анонимный запрос для предоставления определенному пользователю доступа к какой‑либо услуге. Сервер в ответ:
- предоставляет хеш;
- отвечает, что у данного пользователя не выставлен флаг UAF Don't Require PreAuth ;
- говорит, что такого пользователя нет в базе Kerberos.
Выполнить атаку мы можем с помощью скрипта GetNPUsers, входящего в состав пакета скриптов impacket. Задаем скрипту следующие параметры: контроллер домена ( -dc-ip ), способ аутентификации Kerberos ( -k ), опция «без пароля» ( -no-pass ), список пользователей ( -usersfile ) и целевой хост в формате домен/ хост .
GetNPUsers. py -dc-ip 10. 10. 10. 240 -no-pass -k -usersfile users. txt LICORDEBELLOTA/ pivotapi. htb
Нам говорят, что, кроме пользователя Kaorz , в базе Kerberos больше никого нет, причем для учетной записи Kaorz сервер аутентификации вернул нам хеш! Давай разберемся, что это за хеши и почему их раздают кому попало.
Дело в том, что, когда клиент посылает сообщение c идентификатором пользователя на сервер аутентификации и запрашивает доступ к услуге для какого‑то пользователя, сервер аутентификации смотрит, есть ли пользователь в базе Kerberos, после чего проверяет его учетные данные. Если учетные данные неверны, сервер отвечает сообщением UAF Don’t Require PreAuth .
Но есть одно ограничение: у учетной записи пользователя может быть активирован флаг DONT_REQ_PREAUTH , который означает, что для данной учетной записи не требуется предварительная проверка подлинности Kerberos. Для этого пользователя учетные данные не проверяются и сервер аутентификации генерирует секретный ключ, хешируя пароль пользователя, найденный в базе данных. Получается, мы можем пробрутить хеш и узнать пароль пользователя!
Брутить хеш будем по словарю программой hashcat. При запуске нам нужно передать номер типа хеша (параметр -m ), поэтому сначала узнаем его, запросив справку и отфильтровав только нужный нам тип.
Искомый номер — 18200. Теперь запускаем перебор, при этом в параметрах указываем перебор по словарю ( -a 0 ), тип хеша krb5asrep (-m 18200`), файл с хешем и словарь.
/ wordlists/ rockyou. txt
Очень быстро находим искомый пароль учетной записи Kaorz . Так как у нас появились учетные данные, нужно попробовать с ними подключиться ко всем доступным ресурсам. FTP учетных данных не требует, поэтому проверим SMB. Для этого я обычно использую утилиту smbmap.
В выводе получим список доступных ресурсов SMB и разрешения для каждого. Чтобы долго не ходить по директориям и не искать интересные файлы, есть удобная возможность вывести все содержимое ресурсов рекурсивно. Для этого в smbmap нужно указать опцию -R . Пролистав список, обращаем внимание на каталог HelpDesk , который содержит исполняемый файл и два файла msg , то есть какие‑то сообщения.
Чтобы заполучить файлы, можем запустить любой клиент SMB. Я буду использовать smbclient, поскольку он тоже входит в набор impacket.
smbclient. py LicorDeBellota/ Kaorz: Roper4155@10. 10. 10. 240
Точка опоры
Конвертация MSG
Файл .msg содержит электронное письмо в формате Microsoft Outlook и включает данные отправителя и получателя, тему и текст письма. Также в виде файла .msg может быть сохранена информация о встрече или ином событии из календаря Outlook, данные контакта из адресной книги, сведения о задаче. Его можно конвертировать в обычный текстовый формат с помощью утилиты msgconvert. Но сначала ее следует установить.
sudo apt install libemail- outlook- message- perl libemail- sender- perl Содержимое сообщения Server MSSQL Содержимое сообщения WinRM ServiceВ первом сообщении говорится, что в 2010-е годы была установлена база Oracle, но в 2020 году решили перейти на MS SQL. При этом найденное приложение Reset-Service. exe было создано для рестарта службы Oracle. Что здесь очень важно — это функция логина, то есть приложение работает с учетными данными.
Во втором сообщении упоминается блокировка службы WinRM и исходящего трафика по протоколам TCP, UDP и ICMP.
Анализ приложения, использующего вызов CMD
Перейдем к анализу третьего файла — исполняемого. Откроем его в любом дизассемблере (я использую IDA Pro) и первым делом глянем список импортируемых функций. Это позволит нам составить первое мнение об этой программе и примерно понять, для чего она нужна.
Список импортируемых функций
Обратим внимание на функцию ShellExecuteEx , которая должна выполнять команды в командной строке. Еще здесь много функций для работы с файлами ( DeleteFile , CreateFile , GetTempPathW и прочие). Чтобы наглядно отследить работу с файлами и запуск команд, активируем Process Monitor. После запуска создадим фильтр, который будет отслеживать только наш целевой процесс.
Фильтр Process Monitor
Когда все будет готово, запустим исполняемый файл и просмотрим вывод Process Monitor.
События в Process Monitor
В событиях мы видим создание файлов .tmp и запись (скорее всего, копирование) скрипта .bat. Далее создается процесс командного интерпретатора cmd. exe . А раз он запускается, то мы можем воспользоваться CMDWatcher. Эта утилита будет приостанавливать процесс и показывать аргументы при запуске CMD в любых процессах. Запустим CMDWatcher, а потом анализируемое приложение. Мы увидим, как запускается приложение, а затем — как активируется сценарий bat.
Событие запуска приложения Restart-OracleService.exe Событие запуска файла bat
Пройдем в директорию с запускаемым скриптом и увидим в ней сам скрипт и файл с расширением tmp.
Содержимое каталога /AppData/Local/Temp/
Заглянем в скрипт. В начале видим проверку на запуск от имени определенного пользователя. Сразу сохраняем себе его имя — пригодится! Затем данные записываются в файл C:\ programdata\ oracle. txt . Кодировка напоминает Base64.
Содержимое скрипта
После записи создается еще один файл — C:\ programdata\ monta. ps1 , он содержит код на PowerShell. Этот код считывает данные из файла C:\ programdata\ oracle. txt , декодирует их из Base64 и записывает в C:\ programdata\ restart-service. exe . Затем удаляются и файл с данными Base64, и скрипт на PowerShell и запускается новосозданный исполняемый файл restart-service. exe . После выполнения он удаляется.
Содержимое скрипта
Давай получим этот исполняемый файл для дальнейшего анализа. Для этого немного модернизируем наш батник: в начале скрипта уберем проверку пользователей, а в конце — любые удаления файлов (команда del ), уберем также запуск создающегося исполняемого файла.
Модернизированный bat-скрипт (начало) Модернизированный bat-скрипт (конец)
Запустим измененный скрипт, после чего проверим каталог C:\ programdata , там нас будет ждать файл с данными, скрипт на PowerShell и целевая программа.
Содержимое каталога C:\programdata
Анализ приложения со скрытыми функциями
Исполняемый файл открываем в IDA Pro, чтобы посмотреть импортируемые функции. Но там не было ничего интересного, а для статического анализа файл великоват. Именно по этой причине я решил использовать приложение API Monitor. Оно может отображать все вызовы API-функций вместе с передаваемыми в них аргументами.
После запуска API Monitor нужно указать целевой исполняемый файл, для чего выбираем Monitor New Process. В разделе справа увидим все вызванные приложением функции.
Стартовое окно приложения API Monitor Выбор исполняемого файла Результат анализа файла
Часто вызывается GetProcAddress . Дело в том, что DLL может загружаться приложением не только статически (при запуске), но и динамически (во время выполнения) с помощью функции LoadLibrary . А для получения адреса функции в загруженной DLL как раз используется функция GetProcAddress , которая в качестве параметра получает имя импортируемой функции. Эта техника усложняет статический анализ, а именно скрывает важные функции из таблицы импорта.
Давай узнаем, какие функции хотел спрятать разработчик. Для этого необходимо установить фильтр, чтобы в выводе присутствовали только функции GetProcAddress . В контекстном меню выбираем Include → API Name.
Установка фильтра Отфильтрованный список функций API
Сразу видим множество функций для работы с реестром, но это пока ничего не говорит. Чтобы сложить целостную картину, просмотрим абсолютно все загружаемые функции (это займет 5–10 минут). Во время анализа останавливаемся на CreateProcessWithLogonW . Это важная функция!
Отфильтрованный список API-функций
Она создает новый процесс и его первичный главный поток. Новый процесс затем запускает заданный исполняемый файл в контексте системы безопасности определенного пользователя. Дело в том, что эта функция принимает учетные данные пользователя в качестве аргументов. Давай найдем ее вызов, чтобы получить эти параметры. Для этого выбираем в окне Display пункт Add Filter, а затем указываем условие API Name is CreateProcessWithLogonW .
Создание фильтра Событие вызова функции CreateProcessWithLogonW
Продолжение доступно только участникам
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее
Читайте также: