О тестировании на проникновение написано уже немало книг и статей. Эта тема становится все актуальнее с каждым новым инцидентом ИБ. Злоумышленники проникают в сети различных организаций с целью прямого хищения денег с счетов (банки, финансовые организации), атак на отказ в обслуживании (предприятия критической инфраструктуры), хищения персональных данных и других вредоносных действий. Системы информационной безопасности большинства организаций не способны в полной мере защитить от действий квалифицированных злоумышленников. Причин этому несколько. В России традиционным драйвером рынка ИБ являются требования регуляторов (ФЗ 152, ФЗ 187 и т.д.) и при построении системы защиты прежде всего стремятся выполнить требования приказов ФСТЭК, ФСБ, ЦБ и т.д. Проведя категорирование, построив модель угроз, написав ОРД, спроектировав и внедрив систему защиты заказчик считает что он теперь защищен. Хотя обычно этого недостаточно.

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

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

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

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

Переходим к практике

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

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

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

Дежурный дисклеймер: вся представленная в статье информация приводится исключительно в ознакомительных целях. Перед использованием приведенной информации настоятельно рекомендуется ознакомиться со статьей 272 УК РФ.

Проводим разведку

Итак, приступим. Прежде всего поговорим о том, какую информацию можно собрать об атакуемой организации и ее ресурсах в интернете. Будем считать, что нам известны название организации, официальный сайт и контактная информацию некоторых сотрудников. Начнем с сайта. С помощью сервиса https://whois.ru/  или аналогичных можно получить полную информацию о том, на кого зарегистрирован данный ресурс, какие DNS серверы используются (попутно можно понять у какого облачного провайдера размещен ресурс).

Мы узнали кое-что об официальных ресурсах организации, но мы пока не знаем, где размещается веб сайт на площадке провайдера или в ЦОДе организации, ведь многие компании размещают свои веб ресурсы непосредственно на площадках хостинг-провайдеров, чтобы не осуществлять самим сопровождение веб ресурсов. Итак, у нас есть IP адрес веб сайта, давайте попробуем узнать, кому принадлежит пул, в который входит данный адрес. Воспользуемся сервисом https://2ip.ru/whois, указав имя сайта или полученный ранее IP.

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

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

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

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

IP из почты

Продолжая разговор о внешних подсетях, арендуемых заказчиками есть еще пара способов узнать  IP адреса принадлежащие компании. Для начала с помощью утилиты nslookup узнаем MX записи для данного домена.

Как я уже упоминал в начале статьи, нам известны несколько почтовых адресов, например info@domain.com. Нам необходимо что-то написать на этот адрес и обязательно получить ответ. Далее в любом почтовом клиенте смотрим письмо в формате RFC-822.

Здесь можно увидеть много интересного. Прежде всего мы можем узнать IP адрес сервера отправителя  в поле Sender. Также здесь могут оставлять свои отпечатки антивирус и антиспам. В данном примере отметился антиспам Яндекса. Эта информация нам может помочь впоследствии для проникновения в сеть. IP адрес сервера отправителя по идее должен совпадать с MX записью, которую мы нашли с помощью nslookup но возможны варианты, так что лучше проверить.

Белое на белом

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

Существуют платные сервисы реализующие подобный функционал. Но в принципе логирование обращений можно реализовать самостоятельно, для этого нужен только веб сервер с внешним IP. Регистрировать DNS имя не обязательно, можно обращаться к файлу по адресу. 

В письме помещаем что-то подобное:

<img src="https://IP_адрес/картинка.png">

А на сервере смотрим файл журналов доступа, у меня это /var/log/apache2/access.log. В нем отображается адрес и время обращения к файлу.

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

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

Начнем с сайта

Не секрет, что многие веб страницы содержат уязвимости, однако далеко не все из них можно использовать для дальнейшего развития атаки. Например подмена содержимого страниц сайта конечно может нанести определенный ущерб имиджу организации, но не более. Поэтому мы не будем рассматривать все уязвимости из OWASP TOP 10, а поговорим только об основных моментах по сбору информации. Прежде всего попробуем поискать уязвимости на самом сайте. Для этого воспользуемся бесплатным сканером Nikto который входит в состав Kali Linux. Не забываем о необходимости использовать VPN для сокрытия своих действий на данном ресурсе. У меня в качестве подопытной жертвы выступает сайт http://testphp.vulnweb.com/, разработанный компанией Acunetix для тестирования сканеров уязвимостей.

В полученном отчете нас могут заинтересовать раскрытия различных файлов и информация об используемых версиях ПО. В блоге OTUS есть подробная статья, посвященная работе с Nikto https://habr.com/ru/company/otus/blog/492546/.

 Кроме поиска уязвимостей можно попробовать перебрать каталоги на веб сервере. Очень часто админы веб серверов оставляют доступными на чтение какие-либо каталоги (админские панели, старые версии сайта, бэкапы и т.д.) на которые не ведут ссылки с основного сайта. Однако, эти каталоги можно найти с помощью специальных утилит. Я использую dirb из состава Kali Linux.

В результате перебора мы обнаружили каталог Admin. С помощью такого перебора можно получить общее представление о том, на каком движке крутится веб сайт. Например, наличие большого числа каталогов wp* говорит об использовании WordPress.

Кстати, иногда удается найти папку типа Upload, в которой тоже может быть множество интересной информации. Ну и не стоит пренебрегать обычными поисковиками. Например в Яндексе есть опция Сохраненная копия. Эта опция бывает полезна когда какая-либо страница уже недоступна, а очень хочется узнать что же там было. И конечно помним про старый добрый архив Интернета https://archive.org/.

Еще одна классическая уязвимость из OWASP TOP-10 это SQL инъекция. Суть этой атаки заключается в возможности выполнить собственный запрос к базе данных и получить доступ к закрытой информации. Для поиска таких уязвимостей воспользуемся утилитой sqlmap.

На приведенном скриншоте sqlmap удалось обнаружить две базы MySQL: acuart и information_schema. Для примера посмотрим какие таблицы входят в состав acuart.

Для этого запустим следующую команду:

sqlmap –u http://testphp.vulnweb.com/listproducts.php?cat=1 -D acuart –tables

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

У нас еще есть найденные ранее подсети, арендованные данной организацией. Прежде всего их можно просканировать на наличие открытых портов и выявления используемого ПО. Для этого можно воспользоваться утилитами nmap и masscan. В своем примере я воспользуюсь masscan. На вход необходимо указать сканируемую подсеть и диапазон портов. 

Я сканировал подсеть веб хостинга поэтому у всех открыты порты 80. На самом деле при всей кажущейся неэффективности сканирования портов для внешних подсетей, на деле можно получить довольно интересные результаты, например смотрящие наружу RDP и SSH. И если в случае с SSH часто используется аутентификация по сертификатам и подбирать пароль на эти узлы в общ9999ем случае бесполезно, то в случае с RDP можно добиться куда большего. Например, можно попробовать подобрать пароль, поискать уязвимости и т.д.

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

Заключение

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

В заключение приглашаю всех на бесплатный урок курса Внедрение и работа в DevSecOps, в рамках которого научимся классифицировать уязвимости для web приложений. Также разберем уязвимости OWASP Top 10 для Web приложений, такие как: Broken Access Control, Cryptographic Failures и другие.

• Зарегистрироваться на бесплатный урок