Глава 15. Безопасность корпоративных приложений - базы данных и файловые системы

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

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

NetBIOS может быть определён как Network Basic Input Output System, которая представляет собой устаревший разработанный IBM в начале 1980-х годов для небольших сетей протокол для того, чтобы всякий компьютер в сети мог преобразовать бы преобразовать протокол IP (Internet Protocol) в соответствующее имя хоста, или в целом, имя компьютера.

NetBIOS это 16-digit ASCII символы, назначенные компьютерам в WORKGROUP (рабочей группе) или в неком домене через WINS (Windows Internet Name Service) для разрешения значения имени хоста в его IP адрес. Следующий снимок экрана отображает имя NetBIOS компьютера:

Как показано на Рисунке 15.1, CONSULTANT11-HO это заданное для компьютера имя, потому как каждый подключённый к одной и той же LAN (Local Area Network, локальной сети) компьютер был способен разрешать значение IP адреса этому названию компьютера.

Служба NetBIOS позволяет вычислительной системе запросто взаимодействовать с сетевыми приложениями, такими как принтеры и машины, подключаемые к локальному Ethernet или LAN. NetBIOS очень важен, ибо некоторые более ранние и наследуемые приложения всё ещё пользуются службами NetBIOS для взаимодействия друг с другом.

NetBIOS предоставляет три службы:

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

При помощи утилиты nbtstat мы можем получить очень много сведений относительно NetBIOS поверх TCP/IP и статистических данных протокола. Приводимый ниже снимок экрана отображает работу nbtstat:

Как показано на Рисунке 15.2, при помощи утилиты nbtstat мы имеем возможность выделить все зарегистрированные в сетевом адаптере данного узла машины. Теперь, помимо имени хоста и состояния такой удалённой машины, имеются некоторые интересные сведения в виде шестнадцатеричного кода. Они носят название суффикса NetBIOS. Давайте также взглянем на них:

Для получения полных сведений, пройдите, пожалуйста, по следующей ссылке.

Далее, теперь, когда мы изучили одну утилиту, давайте взглянем на утилиту NMAP для сбора сведений относительно NetBIOS, что показано на следующем снимке экрана:

Как отражено на Рисунке 15.3, NMAP предоставляет много сведений относительно сканирования NetBIOS, например, значение имени хоста машины и его контроллер домена. Злоумышленник может воспользоваться этими сведениями для планирования своей последующей атаки. Таким образом, теперь мы ознакомились с NetBIOS и давайте взглянем на SMB, наиболее важный и выступающий самой распространённой целью протокол для злоумышленников.

Протокол SMB (Server Message Block, блока серверных сообщений) был разработан в начале 1980-х исследователями IBM. Этот протокол SMB выступает протоколом клиент- серверного взаимодействия, применяемого для доступа к открытым совместным ресурсам, файловым серверам, принтерам и многим прочим ресурсам во внутренней сетевой среде.

Основная функциональность SMB состоит в совместном применении файлов между клиентом и сервером. Протокол SMB работает по порту 445, однако изначально он был разработан для работы через порт 139 поверх протокола TCP (Transmission Control Protocol ).

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

Как отображено на Рисунке 15.4, наш клиент запрашивает свой SMB на доступ к некому ресурсу, а после успешной аутентификации, его сервер предоставляет этому клиенту доступ к ресурсу:

Приводимый далее снимок экрана показывает при помощи такого средства отслеживания сети как Wireshark запрос и отклик аутентификации клиент- сервера SMB для доступа к совместному ресурсу ADMIN$:

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

 

Уязвимости

Как нам известно, SMB это одна из самых востребованных служб, а потому давайте попробуем выяснить уязвима ли запущенная служба SMB:

К тому же существует ещё один способ взлома учётных данных домена при помощи атаки ретрансляции NTLM в сочетании с доступом к совместному файловому ресурсу SMB. Конкретно для этой атаки доступно несколько средств, таких как smb_relay, mitm_relay и Metasploit, а также коды сценариев ретрансляции, которые имеются в Python, Responder и т.п. Именно для данной главы мы воспользуемся утилитой Responder, которая предварительно установлена в Kali Linux:

Как мы видим из Рисунка 15.11, по причине ретрансляции SMB, когда наш зарегистрированный в своей машине пользователь Administrator пытается выполнять доступ к сетевому совместному ресурсу, утилита Responder немедленно перехватывает значение хэша NTLM. После этого злоумышленник может воспользоваться этим хэшем NTLM для передачи требуемого хэш- значения для регистрации в машине 10.172.19.51.

Lightweight Directory Access Protocol (облегчённый протокол службы каталогов), или, для краткости , просто LDAP, как и предполагает его название, протокол не просто для доступа к объектам AD (Active Directory ), но к тому же для аутентификации и управления веб приложениями. Тем самым, в случае его компрометации службы LDAP выступают шлюзом к сведениям о золотом руднике, таким как названия, идентификационные номера, персональные сведения, подробности карты, локальные учётные данные и учётные записи.

Следовательно, как и при внедрении SQL, в случае их эксплуатации, инъекции LDAP способны разоблачать гигантский объём сведений относительно инфраструктуры организации и они даже способный снабжать злоумышленников доступом к серверам баз данных и внутренним системам.

Теперь, чтобы собрать сведения о внутренней инфраструктуре, имеется в доступности множество средств, таких как сценарии ldapsearch, NMAP, Python или Perl. Для целей этой главы мы воспользуемся сценариям NMAP чтобы выделить сведения LDAP:

Как показано на Рисунке 15.12, при помощи сценария ldap-rootdse, выводится дамп большого объёма важных сведений относительно текущего исполняемого домена; злоумышленник для построения сценариев атак может пользоваться этой информацией.

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

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

Базы данных или, для краткости, DB (Databases) это собрания структурированных сведений, которые пребывают в безопасности, легко доступны, причём в режиме 24/7. Базы данных хранят любые виды информации, например, персональные данные пользователей, зашифрованные учётные сведения, финансовые записи и промышленные сведения. Таким образом, когда выявляется любая мало-мальски неверная настройка, злоумышленник воспользуется ею для дампа конфиденциальных сведений.

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

Компании выбирают собственные базы данных согласно своим требованиям, но, как правило, среди организаций наиболее популярны MSSQL и Oracle. В данной главе мы в первую очередь сосредоточимся на MSSQ:, поскольку это наиболее распространённая в организациях база данных. Итак, давайте взглянем на MSSQL и некоторые её запросы:

TDS, или Tabular Data Stream (поток табличных данных) это протокол базы данных уровня приложения, используемый для передачи данных между сервером базы данных и клиентом базы данных. Основная проблема TDS состоит в том, что имеющееся соединение между соответствующими клиентом и сервером не зашифрованы, а тем самым, любой злоумышленник способен изменять запросы SQL и добавлять/ модифицировать или удалять столбцы, таблицы, пользователей и тому подобного.

Давайте разберёмся с этим на неком образце:

Как показывает Рисунок 15.18, этот запрос найти зарегистрированных пользователей выполняет отслеживание в обычном текстовом виде и всякий злоумышленник может им воспользоваться для осуществления MITM (Man in The Middle) и прослушивать запросы SQL. Теперь давайте перейдём к другому протоколу SQL.

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

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

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

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

Перебор серверов SQL обычно осуществляется тремя методами:

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

 

Сканирование портов TCP/ UDP

Как нам известно, сервер SQL запускается по порту 1433, в настоящее время наш сервер SQL запущен на службе UDP. Поэтому, воспользовавшись модулем PowerShell PowerUPSQL, запускаем команду Get-SQLInstanceScanUDP, как это показано на приводимом ниже снимке экрана:

Как видно на Рисунке 15.19, в нашем домене установлен SQLExpress, а имя его компьютера определяется как hackme.pal.

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

Из Рисунка 15.20 видно, что наша сборка .NET перечисляет запущенные в нашем домене серверы SQL. Давайте теперь просканируем ту систему, в которой исполняется сервер SQL как локальный экземпляр.

 

Сканирование перечислением локального экземпляра

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

Таким образом, воспользовавшись сценарием PowerShell PowerUpSQL, отсканируем свою локальную машину с запущенными экземплярам как это показано ниже:

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

 

Сканирование перечислением домена

Сканирование перебора домена выполняется путём сканирования SPNs (Service Principal Names, имён главных служб), которые зарегистрированы в одном из конкретных контроллеров домена SQL или же во множестве контроллеров домена для разделения баз данных. Приводимый далее снимок экрана отражает перечисление нашего домена SQL с применением сценария PowerShell PowerUPSQL:

Как видно из Рисунка 15.22, MSSQLSvc это зарегистрированное в нашем контроллере домена имя SPN, а также в этом домене обнаружен сервер SQL.

Итак, раз мы успешно выявили серверы SQL, давайте осуществим простой аудит для идентификации удалённых неверных настроек при помощи PowerUPSQL, NMAP, Nessus, Nishang, SQL scanner или прочих доступных через Интернет средств. Для целей данного курса мы будем целиком полагаться на PowerUPSQL, однако не стесняйте себя и воспользуйтесь и прочими утилитами.

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

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

Как видно из предыдущего Рисунка 15.23, активирована команда аудита SQL. Давайте проверим полученные результаты как это показано на снимке экрана далее:

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

Тогда давайте применим некоторые из таких неверных настроек и скомпрометируем свой сервер.

Итак, после того как мы осуществили аудит неверных настроек, давайте сначала идентифицируем зарегистрированных в этом SQL сервере пользователей при помощи модуля PowerShell PowerUpSQL.

Приводимый ниже снимок экрана отображает подключённых в данный момент времени пользователей в исследуемом SQL сервере при помощи сканирования SPN:

Как мы наблюдаем на Рисунке 15.25, в настоящее время в данной машине зарегистрирован пользователь домена deep1792. Таким образом, давайте взломаем deep1792 простым перебором.

 

Атака простым перебором

Атака простым перебором (brute-force) вовлекает предсказывание пароля пользователя для компрометации удалённой машины или учётной записи пользователя с целью выполнения вредоносных действий.

Аналогичный подход можно применять в случае серверов SQL при помощи большого числа утилит, сценариев или инструментов. Конкретно для данной главы мы воспользуемся тем же самым модулем PowerShell PowerUpSQL, применяя такую команду:

Command - $Accessible | Invoke-SQLAuditWeakLoginPw -UserFile usernames -PassFile pass.txt | Out-GridView
 	   

На снимке экрана ниже показан получаемый вывод:

Как видно из Рисунка 15.26, наш пользователь deep1792 настроен с плохим паролем (password@123), а потому давайте выполним регистрацию и воспользуемся этим сервером SQL на его этапе эксплуатации по завершению.

 

Эксплуатация по завершению

Таким образом, раз мы успешно взломали учётные данные пользователя deep1792, теперь мы можем здесь воспользоваться двумя подходами: либо открыть снабжённый оболочкой сеанс применяя PowerShell и модуль PowerUPSQL, либо воспользовавшись утилитой HeidiSQL. Для данного раздела я остановлюсь на HeidiSQL, но будьте вольны также применять и указанный модуль PowerShell:

На данный момент мы успешно скомпрометировали исследуемый сервер SQL. Помимо этого существует большое число прочих неверных настроек, таких как CLR (Common Language Runtime, среда времени исполнения распространённого языка программирования), заслуживающих доверия баз данных и тому подобных, но все они выходят за рамки данной главы. Тем не менее, будьте свободны от ограничений и попробуйте попробовать и их.

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

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

В данной главе мы изучили весьма углублённые вопросы, которые обычно обязаны применяют участники красной команды для компрометации операций AD и Swift, включая базу данных SQL Swift. Следовательно, очень важно осознавать подход злоумышленника когда какая- либо машина во внутренней сети скомпрометирована удалённым нападающим. В этой главе мы рассмотрели атаку простым перебором SMB, ретрансляцию для компрометации хэша NTLM и неверные настройки SQL сервера через подмену пользователя и xp_cmdshell.

Наша следующая глава сосредоточится на атаках VOIP (Voice Over IP), включая разнообразные технологии компрометации серверов VOIP и сетевых сред VOIP, а также посредника в промежутке (MITM).