1. Введение

Здравствуйте, уважаемые читатели.

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

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

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

2. Атака по цели

В качестве тестовой жертвы будет рассмотрена несуществующая крупная организация "White Hat 631" (все совпадения случайны). Для начала мероприятий по атаке необходима точка входа. Если вы действуете удаленно, то обычно ею выступает сайт организации — в нашем случае whitehat631.com.

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

2.1 Сканирование поддоменов

Самый простой шаг — узнать, какие существуют поддомены у основного домена. Для его реализации существует множество готовых инструментов, напр., Sublist3r. Из онлайн-сервисов можно отметить nmmapper (вкладка "subdomain finder"). Принцип работы таких инструментов можно подсмотреть в реализациях с открытым исходным кодом. Также тут не будет предоставлено подробных инструкций по работе с конкретными инструментами, — достаточно воспользоваться документацией.

Итак, просканировав на вышеописанный предмет домен whitehat631.com, мы получили список из нескольких десятков поддоменов следующего вида:

• mail.whitehat631.com

• dev.whitehat631.com

• gitlab.whitehat631.com

• api.whitehat631.com

• wiki.whitehat631.com

• stat.whitehat631.com

• ...

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

2.2 Сканирование сети

Если организация крупная, то, скорее всего, она будет использовать целую подсеть IP адресов (/24 или больше). Убедиться в этом можно по разному. Cамый простой способ заключается в том, чтобы получить IP адреса нескольких поддоменов (напр., через утилиту ping) и проанализировать их. Допустим, мы это сделали и получили:

• 111.101.102.5

• 111.101.102.37

• 111.101.102.49

• 111.101.102.11

Тут становится весьма вероятным, что организация, по меньшей мере, использует подсеть 111.101.102.0/24 (то есть диапазон адресов 111.101.102.1-111.101.102.255). Неплохой идеей будет желание просканировать на популярные порты весь этот диапазон. Утилита nmap справится с этим за считанные минуты. Просто выполните с рабочего места следующее:

> nmap 111.101.102.0/24

В результатах работы вышеприведенной команды стоит уделить особое внимание нестандартным открытым портам (под стандартными в данном случае считаются только 80/HTTP и 443/HTTPS, т.к. они подставляются в браузерах пользователей по умолчанию в зависимости от протокола). Не исключено, что, напр., по адресу 111.101.102.37:8080 разработчики оставили веб-панель для управления частью инфраструктуры и забыли прикрутить авторизацию. Тем временем, про стандартные порты тоже не стоит забывать — там тоже может быть что-то интересное (особенно если попался IP адрес который не разрешается в (под)домен, т.к. он наверняка не предназначен для общего пользования). Кстати, результаты сканирования удобно сохранять в файл.

Стоит отметить, что обращение напрямую по IP и порту может быть недоступно, если используется концепция виртуального сервера (когда веб-сервер по-разному отвечает в зависимости от присланного в HTTP-запросе хедера Host и т.д.). Наверняка вы замечали, что некоторые сайты (или поддомены одного сайта) при пинге отвечают одинаковым IP — это как раз такое явление. В таком случае можно будет обратиться за помощью к п. 2.1 с целью разрешения IP адреса в (под)домен.

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

2.3. Сканирование путей у найденных веб-сервисов

Итак, на данном этапе надо консолидировать информацию о полученных веб-сервисах в п. 2.1-2.2. Если с первого взгляда на них нет ничего интересного (напр., они могут отвечать ошибкой 404/Not Found на главной странице), то стоит заняться частным случаем фаззинга — просканировать пути. Так можно найти всякого рода админки/копии репозиториев с кодом/бэкапы/элементы управления и получения закрытой информации. Для этого я рекомендую использовать утилиту wfuzz. Так как такое сканирование осуществляется путем перебора, то потребуется хороший словарь (хотя бы на пару десятков тысяч вариантов). Начать искать словари можете, напр., отсюда. Пример работы с wfuzz (который будет исключать 404/403 ответы от сервера и работать в 20 потоков):

> wfuzz -c -u http://stat.whitehat631.com:8080/FUZZ \
	-w dict_30k.txt --hc 404,403 -t 20

2.4. Эксплуатация уязвимостей

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

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

• Отсутствие авторизации в закрытых сервисах организации как таковой;

• Недостаточная проверка прав доступа к частям приложения/сервиса — очень частая ошибка разработчиков и на сегодняшний день;

• Использование старых версий общеизвестных приложений/веб-серверов, для которых существуют доступные вам эксплойты (см. exploit-db.com, cvedetails.com и проч.) ;

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

Стоит отметить, что только лишь веб-сервисами варианты атак не ограничиваются, — можно устроить атаку на роутеры/SIP/VoIP/FTP/E-Mail и/или прочие службы (если они достаточно стары, вы, вероятно, сможете найти для них эксплойты).

Также не все эксплойты подразумевают организацию выполнения удаленного кода (RCE) и/или прочий контроль. Но "не расстраивайтесь", варианты ещё есть. Например, весьма полезным может оказаться уязвимость, которая позволяет выполнять перечисление логинов в приложении. Во-первых, зная логины, можно попробовать подобрать пароли (в скрытых сервисах часто такие пароли просты, нет проверок и ограничений на массовые попытки авторизации) — это всё ещё работает. Для этого используются специальные инструменты для проведения bruteforce-атак. Их великое множество, от hydra до patator.

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

К слову, бывают уязвимости которые позволяют проверить, существует ли тот или иной логин (напр., функция "Забыли пароль?" и/или особенности работы "Skype for business Server" в AD). В таком случае помимо перебора по словарю весьма хорошим подспорьем будет исследование открытых данных об организации (руководство, сотрудники, информация о которых может быть размещена на официальном сайте или в новостях и т.д.). Например, если ген. директора организации зовут Иванов Алексей Николаевич, а в организации используется генерация логинов по определенному алгоритму (что практически наверняка есть в месте где работают множество сотрудников), то его логином может быть ANIvanov, AIvanov, IvanovAN и т.д. Этим примером я хочу показать, что открытые данные тоже могут сыграть хорошую службу при атаке.

Полезным будет и получение доступа к исходным кодам анализируемого сервиса — так увеличиваются шансы атаки на точки с недостаточной фильтрацией и проверкой входных данных (т.е. уязвимости типа LFI также весьма полезны). Например, благодаря анализу исходного кода можно будет составить успешную SQL-инъекцию из нескольких параметров которые участвуют в одном SQL-запросе, обойдя WAF. Методом черного ящика это сделать практически невозможно, а вот зная запрос — вполне.

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

3. Углубление в инфраструктуру

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

Начать можно с анализа внутренней сети на предмет наличия баз данных без авторизации (напр., этим часто грешит Redis, в котором вы сможете найти сессии и проч., что поможет продвинуться на другие сервера). Также можно заново просканировать сеть на предмет наличия внутренних сервисов, которые не были доступны извне, и произвести с ними аналогичные описанным выше процедуры. Закончить можно полным контролем (read,write) над всеми серверами в сети организации.

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

4. Заключение

В данной статье не рассматриваются атаки с помощью методов социальной инженерии, методом "засланного казачка" и т.д., т.к. это не касается технической части.

Надеюсь, вышеописанное поможет вам понять некоторые варианты атак злоумышленниками и защитить свою инфраструктуру чуточку лучше. Можно заметить, что хорошая защита должна работать на нескольких уровнях сразу: приложение, ОС и серверное ПО, организация сети, и т.д. Если что-то из этого будет уязвимо — вы подвергаете высокому риску всё.

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

• Регулярно обновляйте серверное/прикладное программное обеспечение и библиотеки (включая компоненты ОС);

• Закройте всё и вся. Не пытайтесь спрятать что-то (напр., на нестандартных портах) думая что никто не найдет — найдут. Это касается не только внутренних сервисов, но и баз данных и прочих служб;

• Используйте современные средства авторизации и аутентификации (включая n-факторные);

• Производите постоянный мониторинг активности в вашей сети автоматическими системами: кто что загружает, выгружает, сканирует. Уделите этому особое внимание;

• Регулярно меняйте пароли, и следите за их сложностью (длина, необходимые наборы символов и т.д.) автоматизировав это деяние соотв. политиками безопасности;

• Производите инструктаж сотрудников с периодическими контрольными проверками (присылайте им фишинговые письма на e-mail и наказывайте тех кто попался/т.д.) — это также является хорошей точкой входа для атаки на организацию;

• Разграничивайте доступ среди сотрудников, чтобы утечка данных одного не повлекла за собой лавинное обрушение всей системы безопасности.

Мир вашей инфраструктуре.

С уважением,
Петр Осетров.