Самым главным полученным результатом является возможность удаленно управлять параметрами LISTENER на целевом хосте и получать ту самую информацию, которая позволит предпринимать дальнейшие шаги по проникновению в БД.
Для исключения такой возможности и защиты
LISTENER от атак можно (и нужно !) использовать один из двух конфигурационных параметров, определяющих безопасность:
- если требуется удаленное администрирование
LISTENER, необходимо установить пароль командой LSNRCTL> change_password , определив предварительно текущий
LISTENER. После этого без задания пароля нельзя будет использовать никакие команды для остановки или реконфигурирования
LISTENER, включая получение информации о его статусе. Последовательность команд:
LSNRCTL> change_password
Old password: <старый_пароль>
New password: <новый_пароль>
Reenter new password: <новый_пароль> // установлен пароль для доступа к административным действиям
LSNRCTL> set password // требуется ввод пароля для доступа к административным действиям
Password: <новый_пароль> // вводится <новый_пароль>
LSNRCTL> save config
В результате в файле listener.ora для указанного LISTENER появится запись PASSWORDS_<имя_LISTENER> = <ХЕШ_нового_пароля>. Как видно, если локальный доступ на чтение файлов сетевой конфигурации не ограничен, хешированное значение пароля может быть прочитано локальным пользователем.
В Характеристиках и возможностях LISTENER указывается на возможность и описывается механизм подбора паролей для доступа к административным функциям: "Команда set_password без параметра (пароля) заставляет LSNRCTL выдать приглашение для ввода пароля, который перед передачей листенеру будет шифроваться. Однако, если пароль задан в команде set_password, например, “set_password fred”, пароль будет передан листенеру в незашифрованном виде. Это обеспечивает полезную обратную совместимость, но позволяет развернуть атаки на листенер. Читая хеш-значение пароля из файла listener.ora и используя его в команде set_password, нарушитель может обойтись без необходимости знания пароля." Кроме того, если атакующий имеет набор хешей для наиболее вероятных паролей, он может автоматизировать подбор пароля с использованием метода brute force. В случае слишком простого пароля результат может быть получен в относительно короткое время. В случае массовой атаки на LISTENER возможен "отказ в обслуживании" всей системы. Для борьбы с данным нападением возможно использование параметров, определяющих ограничение доступа к Oracle ( не к LISTENER). В файле protocol.ora\sqlnet.ora (версии до 8 включительно и старших версий соответственно ) необходимо добавить параметры:
tcp.validnode_checking = YES
tcp.invited_nodes = {list of IP addresses} // доступ разрешен, перечень адресов через запятую
tcp.excluded_nodes = {list of IP addresses} // доступ запрещен, перечень адресов через запятую
- если требуется запретить любые попытки удаленного администрирования независимо от того, задан ли пароль, в файл listener.ora необходимо включить параметр ADMIN_RESTRICTIONS_<имя_LISTENER> = ON . Применение этого параметра не запрещает команды LSNRCTL> stop и LSNRCTL> reload для остановки и перезагрузки
LISTENER, что это не защищает от простых атак типа “отказ в обслуживании”.
Установка пароля или опции ADMIN_RESTRICTIONS взаимно исключают друг друга, при этом установка
ADMIN_RESTRICTIONS заменяет собой пароль. Установка пароля отключает конфигурационные команды, определенные
ADMIN_RESTRICTIONS. В таком случае необходимо вручную изменять файл
listener.ora, а затем для ввода этих изменений в действие нужно выполнять команду LSNRCTL> reload (с заданием пароля
LISTENER).
Компанией Integrigy разработана простая утилита, проверяющая уровень безопасности LISTENER и дающая рекомендации по его настройке.
Поскольку в рассматриваемом случае АБД не позаботились не только о закрытии информации о параметрах доступа к сервисам, но и о безопасности самого сервиса, в результатах выполнения команд LSNRCTL> status и LSNRCTL> services, сгенерированных утилитой TNScaner201, можно обнаружить много полезной информации для дальнейших действий: версии операционных систем и Oracle, путь к файлам сетевой конфигурации, время работы БД, открытые порты для дополнительных сервисов, интенсивность соединений и режим работы БД. Отметим факт, что одна из БД обеспечивает 21303 DEDICATED соединений за 31 сутки работы, а вторая 4 DEDICATED соединений за 12 работы часов на FTP-сервис БД. Кроме того, каждый из обнаруженных LISTENER обслуживает по одному экземпляру Oracle.
Но самое главное, что дает анализ - имена сервисов, обслуживаемых каждым LISTENER, что в сочетании с именем хоста и номером прослушиваемого порта позволяет обратиться уже непосредственно к базе данных.
Доступ к БД может быть организован и без участия LISTENER. Для этого в файле init.ora следует указать подобные параметры:
mts_dispatchers='(address=(protocol=tcp)(host=sity.ca.ins.edu)(port=5010))(connections=300)',
'(address=(protocol=tcp)(host=sity.ca.ins.edu)(port=5012))(connections=30)',
'(address=(protocol=tcp)(host=14х.16х.3х.13х)(port=5011))(connections=300)'
В этом случае LISTENER может быть остановлен. Запущенные процессы-диспетчеры будут отвечать на запросы утилиты TNSPING, но не будут отвечать на команды управления
LISTENER. Недостатком является то, что для соединения с БД в этом случае имя сервиса (также и SID) не имеет никакого значения и в параметрах линии связи на стороне клиента можно указать любую комбинацию, например - (SID = orcl). Выбор способа соединения должен определяться с учетом иных факторов, влияющих на состояние системы.