Hardening на практике

В преддверии старта курса «Administrator Linux. Professional« подготовили статью, автором которой является Александр Колесников. Если вам интересно узнать подробнее об обучении на курсе, приходите на демо-день курса.

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

Hardening

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

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

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

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

Для закрытия всех векторов атак разобьем их группы:

1. Атаки, которые работают в приложениях доступных во внешний мир

2. Атаки, которые работают внутри ОС и их цель повышение привилегий

Для первого вида атак можно использовать сканеры безопасности. Мы будем использовать набор инструментов машины Kali Linux. Это nmap, Burp Suite и т.д.

Для второго типа атак предлагаем ознакомиться с вот этим проектом. Так как процедура поиска неверных конфигураций в большинстве случаев детерминирована, то это просто автоматизировать. Запускаем команду для получения данных конфигурации и парсим результат — готово. Использовать скрипы достаточно просто, необходимо выбрать нужный для платформы и скопировать его в рабочую директорию уязвимой машины. Скрипты не запускают никаких атак, единственная их задача это показать, что уязвимость может присутствовать в системе и предложить ссылку на статью с атакой. Скрипт это автоматизация и поэтому следует ожидать, что он может давать ложные срабатывания на вероятные уязвимости. Каждый отдельный случай придётся рассматривать отдельно.

Уязвимые стенды

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

echo $RANDOM % 5 + 1 | bc

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

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

Эксперимент

Для первого эксперимента будем использовать вот этот box. Проведем эксперимент в 2 этапа.

Этап 1 — поиск уязвимых конфигураций и сервисов работающих снаружи сервера. Первые команды для запуска:

nmap -n -A -p- --max-rate=1000 machine.ip.address

В результате вот такой список сервисов, которые видны извне сервера:

У нас есть доступ к пользователю внутри машины, поэтому еще попробуем узнать какие порты открыты:

netstat -tulpn

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

dirb http://machine.ip.address

Итог работы инструмента:

Похоже, что это wordpress. в директориях сервера лежит версия WordPress 5.6 и плагин «contact-form». Для этого набора данных очень хорошо подходит CVE-2020-35489. Тестовый скрипт можно найти тут. Попробуем протестировать сервис. Скрипт так и не захотел работать, но по сути их него функциональна только одна строка, которая отправляет запрос на адрес «/wp-content/plugins/contact-form-7/readme.txt». Если его выполнить, то можно увидеть, что используемый плагин может быть уязвим для атаки.

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

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

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

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

Узнать подробнее о курсе «Administrator Linux. Professional«