А АThursday, 13 May 2021

Проводим пентест, часть 3 - ищем уязвимости.

Всем привет.

Сегодня третья часть из серии публикаций Андрея Бирюкова, посвященных проведению аудита и теста на проникновение(пентест). Оригинал статьи был опубликован в журнале "Системный администратор" №06(163), июнь 2016.

Часть 3. Ищем уязвимости.

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

В  предыдущих  двух  статьях  цикла  [1, 2]  мы  собирали  информацию об атакуемой сети и пытались проникнуть внутрь посредством беспроводных каналов связи. Будем считать, что  находимся  в  атакуемой  сети,  нам  известны  подсети, адресация, маски, шлюзы, активные узлы и прочая полезная информация. Мы уже знаем, какие операционные системы и версии прошивок используются. Можем приступить к взлому.

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

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

Итак, у нас есть некий список идентифицированного ПО. 

Алгоритм наших дальнейших действий в рамках данной статьи будет следующим:

  • Поиск учетных записей по умолчанию (если применимо).
  • Проверка данных аккаунтов.
  • Сканирование на наличие уязвимостей.
  • Эксплуатация данных уязвимостей и получение доступа.

Поиск учетных записей по умолчанию.

Начнем  с  самого  простого,  а  именно  попробуем  подключиться к узлам в сети жертвы с помощью учетных записей по умолчанию. В  данном  контексте  учетными  записями  по  умолчанию мы будем называть технологические аккаунты, которые создаются при первичной инициализации устройства или ПО. Такие записи особенно актуальны для различного сетевого оборудования, прежде всего точек доступа к беспроводным сетям. Конечно,  все  вендоры  настоятельно  рекомендуют  менять пароли после инициализации. Но мой опыт показывает, что особенно в сетях крупных организаций это правило совершенно  не  выполняется.  Произведя  первоначальную установку с паролями по умолчанию, администраторы потом просто забывают про свои устройства и вспоминают о них только в случаях сбоев. При этом сисадмины, как будет описано далее, судорожно ищут эти заводские пароли в документации вендоров. Для  того  чтобы  узнать  учетные  записи  по  умолчанию, прежде всего необходимо обратить к руководству по установке, которое можно найти на сайте разработчика данного устройства. Так как модель устройства нам известна, поиск документации  не  должен  составить  большого  труда.  Зачастую,  чтобы  найти  нужное,  достаточно  воспользоваться Google. Но когда в сети жертвы имеется целый «зоопарк» устройств, ускорить процесс поиска учетных записей по умолчанию можно с помощью ресурсов, подобных [3]. А что делать, если в сети несколько десятков различных сетевых устройств? Процесс подключения к каждому из них для проверки правильности учеток по умолчанию может занять продолжительное время. Кроме того, такая активность может быть обнаружена системами мониторинга.

Здесь нам на помощь приходит утилита 56_RouterScan. Она не входит в состав Kali Linux и работает под Windows. Эта программа позволяет автоматизировать описанные ранее действия. Она сканирует сеть на наличие «живых» узлов и открытых портов. Затем, в случае если удалось идентифицировать сервисы на узле (например, модель сетевого устройства), утилита пытается подключиться к нему с паролем по умолчанию. В случае успешного подключения мы получаем имя учетной записи по умолчанию. Также RouterScan может производить попытки подключения с учетными записями, заданными пользователем.  Это  полезно  тогда, когда  нам  известен  пароль  от  одной учетной записи и мы хотим проверить, подойдет ли он к другим устройствам. Очень часто бывает, что администраторы  используют  единую  учетную запись  на  большом  количестве  устройств.

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


Поиск уязвимостей.

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

Термином  «уязвимость»  (по-английски  –  vulnerability) обычно называют недостатки в системе, с помощью которых 



Рисунок 1. Наименование веб-сервера IIS в перехваченном пакете.

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

Существует несколько видов уязвимостей:

- недочеты, допущенные при проектировании системы,

- ошибки в исходном коде,

- ненадежные настройки целевой системы после внедрения.

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

Уязвимости проектирования.

Данный  тип  ошибок  обычно  появляется  задолго  до  того, как  написана  первая  команда  исходного  кода  будущего приложения.  Когда  проектировщики  еще  только  думают,  как  будет  работать  их  система,  они  могут  не  учесть или  сознательно  пренебречь  тем  или  иным  обстоятельством, что впоследствии приведет к серьезной уязвимости в уже разработанном решении. Классическим  примером  является  семейство  технологий пакетной передачи данных Ethernet, разработанное более 30 лет назад. В то время никто не задумывался о проблеме  прослушивания  трафика,  в  результате  в  стандарт не было заложено шифрование трафика. И теперь при использовании  таких  протоколов,  как  Telnet,  FTP  или  HTTP, передаваемые  данные  не  защищены  от  прослушивания. Именно уязвимости проектирования мы использовали, когда прослушивали сетевой трафик. Очевидно, что уязвимости проектирования крайне сложно  устранить.  Обычно  проблему  устраняют  за  счет  расширения  –  HTTPS,  FTPS.  Однако  добавить  шифрование в Ethernet практически невозможно. Для этого придется выпускать новую версию Ethernet. Но  уязвимости  проектирования  широко  известны, и при внедрении своих решений можно своевременно принять меры по предотвращению их эксплуатации.

Уязвимости разработки.

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

#include <string.h>

int main(int argc, char *argv[])

{

  char c[12]; // для переменной c зарезервировано 

       // 12 байт

  strcpy(c, argv[1]); // копируем переданные 

        // из командной строки данные

        // в переменную c

  return 0;

}

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

Следующая программа не подвержена уязвимости переполнения буфера:

#include <string.h>

int main(int argc, char *argv[])

{

  char buf[12];

  strncpy(c, argv[1], sizeof(c));

  return 0;

}

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

Уязвимости внедрения.

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

В случаях с базами данных MS SQL это использование учетной  записи  sa  для  взаимодействия  приложений  и  БД. Как  известно,  для  этого  необходимо  создать  отдельную учетную запись с ограниченным набором прав, а не использовать административный аккаунт. Уязвимости  внедрения  относительно  легко  обнаружить при проведении аудита безопасности, однако они не менее опасны, чем описанные выше ошибки при разработке программ. Ведь как бы хорошо ни было написано приложение, все его элементы защиты становятся бесполезными, если администратор использует простой пароль из «словаря». Уязвимости  проектирования  и  внедрения  мы  уже  рассмотрели:  первые  при  использовании  снифферов  и  вторые при проверке паролей по умолчанию. Теперь перейдем к  наиболее  сложным,  но  интересным  уязвимостям  разработки.

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

Если, к примеру, на компьютере с Windows 7 не установлен Service  Pack  1,  то  система  может  содержать  уязвимости, закрытые  в  SP1.  Однако  такой  путь  не  слишком  удобен, так как требует значительного времени на их поиск. Гораздо  лучше  поручить  эту  операцию  специальному  сканеру. 

Мы  рассмотрим  проведение  сканирования  на  уязвимости с помощью Nessus и OpenVAS. Сканер Nessus не входит в состав Kali, однако разработчики из компании Tennable подготовили специальную сборку для данной ОС [4]:

root@kali:/root# dpkg –i "Nessus-6.6.2-debian6_amd64.deb"

Запускаем службу:

root@kali:/root# /etc/init.d/nessusd start

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

Выбираем  Policies,  далее  New  policy,  Advanced  Scan. 

Далее  присваиваем  имя  новой  политике  и  настраиваем ее  свойства  в  левой  части  окна.  В  принципе  для  начала все можно оставить по умолчанию, разве что в подразделе Permissions раздела Basic я разрешил Default работать с данной политикой (Can use).

В  случае  если  мы  собираемся  сканировать  сетевые принтеры (очень часто содержат уязвимости), необходимо в  разделе  Discovery  выбрать  Scan  Network  Printers.  Далее сохраним нашу политику.

Далее нам необходимо запустить сканер. Для этого выбираем Scans в верхней части экрана, New scan -> User. Затем выбираем нашу политику. На следующем шаге указываем наименование задачи сканирования и в поле Targets указываем цели сканирования. Сохраняем созданную задачу. Теперь в разделе Scans у нас появилось новое сканирование. Запускаем эту задачу.



Рисунок 2. Найденные сканером Nessus уязвимости.

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

Уязвимости,  помеченные  красным  цветом,  наиболее опасны.  Что  со  всем  этим  делать  дальше,  мы  поговорим в следующей статье, а сейчас я рассмотрю работу со сканером OpenVAS.

Многие могут задаться вопросом: зачем проверять вторым сканером, если мы уже использовали Nessus? Здесь все  аналогично  антивирусам:  у  каждого  свое  ядро,  и  то, что один пропустил, другой вполне может определить. Поэтому, если один сканер не нашел интересных уязвимостей, рекомендую «пройтись» другим – возможно, найдется что-то новое.

OpenVAS  является  ответвлением  от  проекта  Nessus. Для установки OpenVAS необходимо выполнить следующие действия:

root@kali:~# apt-get update

root@kali:~# apt-get dist-upgrade

Обновление пакетов будет не лишним.

root@kali:~# apt-get install openvas

После установки запускаем установку сканера.

root@kali:~# openvas-setup

Открываем https://127.0.0.l1:9392. Вводим те учетные данные, которые нам выдали при установке. Для начала необходимо сконфигурировать задачу сканирования. Идем в раздел Configuration – Scan Configs. Далее выбираем политику Full and fast ultimate и клонируем ее, нажав на значок овечки. Теперь отредактируем клон, нажав на значок гаечного ключа. Прежде всего даем политике название, остальные опции оставляем без изменения, но учитываем, что safe_check – отключение данной опции позволит запускаться потенциально опасным  NVT-тестам,  выполнение  которых  может  вызвать сбои в работе хоста.

Далее  устанавливаем  цели  сканирования  в  разделе Configuration – Target. Прописываем цели сканирования, диапазон портов можно оставить без изменения. Затем запускаем сканирование, выбрав раздел ScanManagement – Task. По окончании работы получаем отчет, аналогичный приведенному на рис. 3. Для более глубокого ознакомления с Nessus и OpenaVAS рекомендую почитать  документацию  на  сайтах  проектов.


Рисунок 3. Найденные сканером OpenVAS уязвимости.

Делаем выводы.

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

Что  касается  работы  со  сканерами  уязвимостей, то при проведении аудита я бы не рекомендовал использовать Nessus или OpenVAS для проверки сразу большого числа узлов, например целой подсети. Конечно, один раз это можно сделать, для того чтобы увидеть, как сетевые IDS, система управления событиями безопасности и другие средства защиты (если, конечно, они у вас есть) отреагируют на такое массовое сканирование-атаку. Однако не  стоит  рассчитывать,  что  так  будет  действовать  злоумышленник.

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

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

А теперь поговорим о том, как бороться с уязвимостями. 

Абсолютно  все  разработчики  настоятельно  рекомендуют устанавливать обновления безопасности сразу после их выпуска.  Но  большинство  администраторов  критичных  сервисов обычно не спешат это делать. Они объясняют свою нерасторопность  тем,  что  установка  обновлений  может привести к недопустимым сбоям в работе. Это точка зрения имеет право на существование, и для таких сервисов я бы рекомендовал  использовать  решения  класса  Application Firewall,  которые  позволяют  устанавливать  «виртуальные» патчи, то есть блокировать попытки эксплуатации незакрытых на целевых узлах уязвимостей. А для рабочих станций и некритичных серверов должны быть развернуты тестовые машины с типовыми ОС и приложениями, на которых все обновления должны обязательно тестироваться перед установкой на боевые системы. Для  сетей,  содержащих  большое  количество  машин под  управлением  ОС  Windows,  необходимо  использовать  бесплатный  сервис  Windows  Server  Update  Services (WSUS)  [5],  который  позволяет  осуществлять  централизованное  управление  обновлениями  продуктов  Microsoft. Групповые  политики  должны  устанавливать  обновления  на  пользовательские  машины,  но  не  перезагружать их без согласия пользователя. В противном случае администраторы рискуют получить массу негатива от бухгалтеров, лишившихся квартальных отчетов после внезапной перезагрузки компьютера.

Также  рекомендую  на  регулярной  основе  производить сканирование  сети  на  наличие  уязвимостей.  Эту  задачу лучше выполнять в нерабочее время, так как я уже говорил, что сканирование вызывает серьезную нагрузку на сеть. Здесь  можно  воспользоваться  как  уже  описанными Nessus  и  OpenVAS,  так  и  полностью  коммерческими  решениями типа Max Patrol от Positive Technologies. Но здесь следует помнить, что Nessus для коммерческого использования также является платным. Для Windows сетей можно воспользоваться  бесплатными  анализаторами  уязвимостей Microsoft Baseline Security Analyzer (MBSA) и Microsoft Security Assessment Tool (MSAT) [6].

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

[1]  Бирюков А. Проводим пентест. Часть 1. Проникаем в беспроводную сеть. //«Системный  администратор»,  №4,  2016  г.  – С. 40-44 (http://samag.ru/archive/article/3171).

[2]  Бирюков  А.  Проводим  пентест.  Часть  2.  Сбор  необходимой информации.  //  «Системный  администратор»,  №5,  2016  г.  – С. 27-31 (http://samag.ru/archive/article/3190).

[3]  База паролей по умолчанию для различных устройств – http://routerpasswords.com.

[4]  Страница  Nessus  –  http://www.tenable.com/products/nessus/select-your-operating-system.

[5]  Страница  WSUS  –  https://technet.microsoft.com/ru-ru/security/cc297183.

[6]  Страница  MBSA и MSAT –  https://technet.microsoft.com/ru-ru/windowsserver/bb332157.aspx.

Продолжение следует.

No comments:

Post a Comment

А что вы думаете по этому поводу?

Версия на печать

Популярное