Профессиональное тестирование на проникновение

18 Сентября 2017

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

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

Тестирование на вторжение

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

Основное отличие теста на вторжение – «хакер» обязан найти не все доступные слабости, а лишь те, что подойдут для выполнения четко поставленной задачи (так же, как и при реальном проникновении). Ввиду того, что идет практическое использование слабостей системы, подобные действия могут отрицательно отразиться на работе всей IT-структуры: зависания и перегрузка серверов заметно прибавят работы системным администраторам и вовсе не обрадуют начальство.

Мониторинг незащищённости системы

Что бы вы сделали, если б пришлось взламывать веб-сайт «голыми руками»? Во-первых, попытались бы узнать версию задействованного веб-сервера или системы CMS. А все для того, чтоб примитивнейшим образом найти (даже через поисковик) сведения в Интернете об уже найденных слабостях и созданных эксплойтах. То же самое делали хакеры и 10 лет назад, то же они делают и сегодня.

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

Использование сканеров незащищённости дает возможность оперативно исправить все найденные проблемы и реорганизовать IT-структуру. Однако логика таких анализаторов линейна, то есть, они легко пропустят усложненные сочетания слабостей, создающие все вместе огромную «дыру» в системе защиты.

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

Чтобы и ему, и, естественно, нам было удобнее, он открыл локальный доступ к папке с готовыми образами. И мы не брезгуем воспользоваться такой любезностью, чтобы «вытащить» хэш пароля администратора, который придется «раскручивать» целую ночь. Но в результате мы получаем администраторский доступ всего за один день! Обычный сканер уязвимостей нашел бы эту «шару», но проверка того, что там внутри и «раскрутка» хэшей – уже не его компетенция.

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

Исследование, или анализ, конфигурации

Любая составляющая IT-структуры (операционная система, система управления БД, действующая сетевая аппаратура и многое другое) имеет огромное количество самых различных настроек, определяющих ее степень защиты. Оптимальные устанавливаемые параметры можно отыскать в документах вендора или в публикациях профессионалов, которые делятся своим опытом. Основываясь на подобной информации, организации, вроде National Institute of Standards and Technology, на протяжении многих лет составляют чек-листы, которые позволяют выполнять анализ конфигураций разных систем.

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

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

Задача тестов защищённости

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

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

Полноценное тестирование защиты

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

Саму операцию тестирования можно разбить на несколько шагов, соответствующих манипуляциям настоящего проникновения:

1. Постановка задачи.

2. Выявление слабостей системы.

3. Их использование.

4. Получение привилегированных прав и распространение влияния.

Этап 1: Постановка задачи

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

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

На этом этапе нам предстоит изучить и сделать:

• Веб-ресурсы, взаимодействующие с организацией клиента, а точнее: соответствующие домены, e-mail’ы, организационную структуру и прочее.
• Сайты вакантных мест: узнаем, кто необходим IT-директору клиента.
• Сайты компаний, поставлявших нашему заказчику некоторые IT-средства/услуги. Что, в какое время и каким образом они сделали.
• Запросить в сервисе whois список зарегистрированных на клиента сетей и используемых провайдеров IP-адресов.
• Узнать, есть ли у клиента веб-ресурсы с доменными именами 3 уровня (например, vpn.например.ком, ftp. например.ком и т.п.), запрашивая информацию у DNS-серверов.
• Найти используемые клиентом почтовые сервисы.

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

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

Этап 2: Выявление слабостей системы

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

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

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

Этап 3: Использование уязвимостей

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

1. Чтобы закрыть какую-либо брешь в системе защиты, несчастным системным администраторам придется попотеть, а будто им и без того делать нечего. Ко всему прочему, различные структурные компоненты имеют свойство «отваливаться» после установки даже небольшого патча или переконфигурирования. Потому стоит загружать сисадминов лишь теми проблемами, которые несут реальную опасность. А степень опасности уязвимостей проверяется при их использовании.

2. Некоторые слабости можно проверить только в ходе эксплуатации (плохой пароль, возможность инъекции SQL или XSS).

Чтобы все это выяснить, необходимо:

• Осторожно воспользоваться эксплойтами.
• Перехватить трафик, используя ARP-poisoning.
• Подобрать пароли.
• «Раскрутить» найденные парольные хэши.
• Проверить возможность инъекции SQL или XSS и прочих атак, характерных для веб-приложений.
• Сделать много чего еще. Все зависит от определенной IT-структуры клиента.

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

Этап 4: Получение привилегированных прав и распространение влияния

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

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

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