Что такое tns базы данных
(ADDRESS = (PROTOCOL = TCP) (HOST = aria.us.oracle.com)(PORT = 1521))
(ORACLE SID = ora816)
Теперь, когда клиентскому ПО известно, куда подключаться, оно открывает соединение через сокет TCP/IP к порту 1521 машины aria.us.oracle.com. Если администратор базы данных соответствующего сервера настроил службу Net8 и запустил процесс прослушивания, это подключение может быть принято. В сетевой среде на сервере работает процесс TNS Listener. Это процесс прослушивания, обеспечивающий физическое подключение к базе данных. Получив запрос на подключение, он проверяет его, используя собственные файлы конфигурации, и либо отвечает отказом (например, не существует запрашиваемой базы данных или IP-адрес подключающегося содержится в списке тех, кому не разрешено подключение к хосту), либо обеспечивает подключение клиента.
ляется на него, и тем самым обеспечивается физическое подключение. В случае ОС UNIX это можно представить следующей схемой:
В режиме MTS процесс прослушивания работает иначе. Ему известно, какие процессы-диспетчеры работают в составе экземпляра. При получении запроса на подключение процесс прослушивания выбирает процесс-диспетчер из пула доступных диспетчеров. Затем он посылает клиенту информацию, позволяющую подключиться к процессу-диспетчеру. Это необходимо, поскольку процесс прослушивания работает на известном порту соответствующего хоста, а вот диспетчеры будут принимать подключения через произвольно выделенные порты. Процессу прослушивания известны эти выделенные порты, поэтому он автоматически выбирает свободный диспетчер. Затем клиент отключается от процесса прослушивания и подключается непосредственно к диспетчеру. В результате устанавливается физическое соединение с СУБД. Графически это можно представить так:
Итак, обзор архитектуры Oracle закончен. Мы описали, что такое экземпляр Oracle, что такое база данных и как можно подключиться к базе данных через выделенный и разделяемый сервер. На следующей схеме показано взаимодействие с сервером Oracle клиента, подключенного к разделяемому серверу, и клиента, работающего с выделенным серверным процессом. Один экземпляр Oracle может поддерживать оба типа подключений одновременно:
Теперь подробно рассмотрим процессы, образующие сервер, их назначение и взаимодействие друг с другом, а также содержимое области SGA и назначение ее компонентов. Но начнем мы с описания различных типов файлов, которые сервер Oracle использует для управления данными.
В состав базы данных и экземпляра входит шесть типов файлов. С экземпляром связаны файлы параметров. По этим файлам экземпляр при запуске определяет свои характеристики, например размер структур в памяти и местонахождение управляющих файлов.
Базу данных образуют следующие файлы.
Файл1 данн1х. Собственно данные (в этих файлах хранятся таблицы, индексы и
все остальные сегменты).
Файл1 журнала повторного в1полнения. Журналы транзакций.
Управляющие файл1. Определяют местонахождение файлов данных и содержат другую необходимую информацию о состоянии базы данных.
Временн1е файл1. Используются при сортировке больших объемов данных и для хранения временных объектов.
Файл1 паролей. Используются для аутентификации пользователей, выполняющих
администрирование удаленно, по сети. Мы не будем их подробно рассматривать.
Наиболее важны первые два типа файлов, поскольку именно в них хранятся накопленные данные. В случае потери остальных файлов хранящиеся данные не пострадают. Если будут потеряны файлы журнала повторного выполнения, некоторые данные могут быть потеряны. Если же будут потеряны файлы данных и все их резервные копии, данные, безусловно, будут потеряны навсегда.
Теперь давайте детально рассмотрим все типы файлов и их содержимое.
Что такое TNS: слушатель в контексте Oracle?
пограничный вопрос ServerFault, но решил, что сначала попробую здесь, так как мне повезло с вопросами Oracle в прошлом.
Я пытаюсь подключиться к базе данных oracle из PHP, и я получаю следующую ошибку.
это ошибка, которую сообщает PHP, и ошибка, которая появляется в прослушивателе Oracle.бревно.
Это в среде разработки, которая работает на моей локальной машине windows и работает до сих пор. К сожалению, окружающая среда была передана мне (я ее не настраивал) и людям, которые сделал set it up недоступны, чтобы помочь мне отладить его.
Если бы я получал аналогичную ошибку с MySQL или PostgreSQL (две системы, с которыми я более знаком), я бы проверил, чтобы убедиться, что процесс базы данных запущен, а затем попытался подключиться вручную в базу данных, используя строку username/password / connection. К сожалению, я не знаком с инструментами Oracle в windows (кроме разработчика SQL), и я не знаю, что такое TNS:listener или SID в контексте Oracle (у меня есть смутные идеи, но смутные идеи редко помогают, когда вы отлаживаете что-то вроде этого)
любой общий совет был бы признателен.
обновления для комментариев:
есть несколько entires в моем файл tnsnames.файл ora, соответствующая запись
Это не отражается в списке экземпляров, когда я запускаю
поэтому я думаю, что мой следующий вопрос: как я могу попытаться вручную запустить экземпляр OBS2?
3 ответов
имя TNS похоже на псевдоним вашего экземпляра службы. Служба прослушивателя TNS действует как своего рода служба поиска для вас в этом отношении. Это не сработает с этим сообщением об ошибке, если фактическая служба, к которой вы пытаетесь подключиться через имя TNS, неверна.
затем вы можете проверить, правильно ли прослушиватель TNS видит службу с помощью инструмента командной строки:
который должен вывести что-то вроде следующего:
вы можете пожалуйста, разместите соответствующую запись TNS (в )? Он расположен в ORAHOME\client или db\ADMIN\NETWORK. Если у вас есть клиент и сервер, убедитесь, что обе копии tnsnames.ora файл имеет правильные значения, просто для безопасности.
вот пример правильного определения имени TNS в tnsnames.ora называется «mydb»:
просто хотел добавить к этому, так как у меня недавно была аналогичная проблема с подключением, которая сводила меня с ума, пока я не понял, что происходит.
во-первых, ключевые слова SID и SERVICE_NAME не совсем одинаковы. Это было мое первое неверное предположение. Во многих средах вы можете обмениваться SID и SERVICE_NAME, но не всегда, это зависит.
тем не менее, ваша ошибка выдает проблему: вы указываете ОМР в строке подключения вместо ИМЯ_СЛУЖБЫ что tnsnames успешно использует.
Итак, если вы указываете строку подключения в своем коде, попробуйте использовать ключевое слово SERVICE_NAME в строке подключения (*или, если вы уже используете SERVICE_NAME и не можете подключиться, попробуйте использовать ключевое слово SID*).
слишком упрощенный ответ я знаю, но легко попробовать и может спасти кого-то от головной боли.
надеюсь, это поможет.
ответ Майка Атласа довольно полный, но обратите внимание, что вы можете подключиться к 10G (или более поздней версии) DBs, у которых нет опубликованного tnsname, используя [//]host_name[:port][/service_name]
Глоссарий терминов публикации Oracle
Для администрирования и настройки конфигурации публикации Oracle необходимо ознакомиться со следующей терминологией Oracle. Полный список терминов Oracle см. в электронной документации Oracle.
Индексно организованные таблицы (IOT)
Таблица, данные которой физически отсортированы на диске в индексном порядке; аналог таблицы Microsoft SQL Server с кластеризованным индексом. IOT реплицируется на подписчик в виде таблицы с кластеризованным индексом.
Экземпляр
База данных Oracle связана с экземпляром. Экземпляр содержит память и фоновые процессы, поддерживающие базу данных. Экземпляр Oracle всегда сопоставляется с одной базой данных, тогда как экземпляр SQL Server может содержать множество баз данных. Существуют обстоятельства, при которых база данных Oracle может иметь несколько экземпляров.
Прослушиватель Oracle
Обрабатывает входящий сетевой трафик для экземпляра базы данных Oracle. При настройке сетевого подключения к базе данных Oracle указывается протокол, по которому отсылается трафик, и порт, на котором прослушиватель прослушивает трафик. Прослушиватель обычно настраивается на запуск на том же компьютере, на котором выполняется экземпляр базы данных Oracle, и может быть настроен для работы с одним или несколькими экземплярами.
ROWID
Указатель расположения определенной строки базы данных. Поскольку извлечение строк с использованием ROWID происходит быстрее, чем при использовании просмотра таблицы или индекса, репликация использует ROWID в течение периода обработки опубликованных изменений таблицы.
Sequence
Объект базы данных, который используется для формирования уникальных чисел. Репликация использует последовательности дл упорядочивания изменений, произведенных в опубликованных таблицах.
SQL*Plus
Приложение, используемое для доступа и отправки запросов к базам данных Oracle. Похоже на программу SQL Server sqlcmd.
Синоним
После публикации базы данных Oracle последующие попытки переустановить конфигурацию издателя для использования иного распространителя SQL Server будут неудачны, поскольку этот открытый синоним идентифицирует определенный распространитель с установленной конфигурацией для обслуживания издателя.
Табличное пространство
Элемент хранилища базы данных, примерно эквивалентный группе файлов в SQL Server.
Имя службы TNS
Протокол TNS (Transparent Network Substrate) — уровень связи, используемый базами данных Oracle. Имя службы TNS — это имя, с которым экземпляр базы данных Oracle представлен в сети. Имя службы TNS назначается при настройке подключений к базе данных Oracle. Репликация использует имя службы TNS для идентификации издателя и установки подключений.
Пользовательская схема
Listener Oracle
Стас Белков
Автор статьи. Известный специалист в мире IT. Консультант по продуктам и решениям Oracle. Практикующий программист и администратор баз данных. Подробнее.
Листенер (слушатель) Oracle Net Listener — служба, которая действует только на сервере и прослушивает входящие запросы на подключение. Oracle предоставляет утилиту lsnrctl, управляющую процессом листенера. Место слушателя в сетевой обработке Oracle можно кратко описать следующим образом.
Файл listener.ora, который по умолчанию размещается в каталоге $ORACLE_HOME/network/admin в системах UNIX и в каталоге $ORACLE_HOME\network\admin в системах Windows, содержит информацию о конфигурации Listener Oracle. Поскольку служба слушателя действует только на сервере, клиентские компьютеры не содержат никакого файла listener.ora. Типичный файл listener.ora приведен в листинге ниже.
Все параметры конфигурации в этом файле имеют значения по умолчанию. Поэтому службу листенера не обязательно конфигурировать вручную. После создания первой базы данных на сервере служба TNS Listener Oracle автоматически запускается, и файл конфигурации слушателя, listener.ora, помещается в каталог, определенный по умолчанию. При создании новой базы данных ее информация о сетевых подключений и службах автоматически добавляется в файл конфигурации tns listener Oracle. При запуске экземпляра база данных автоматически регистрируется в слушателе, и слушатель начинает прослушивать запросы на подключение к этой базе данных.
Процесс PMON Oracle отвечает за динамическую регистрацию имен служб баз данных Oracle в листенере (Listener) — при создании новые базы данных Oracle будут автоматически регистрироваться в службе TNS Listener Oracle. Процесс PMON будет обновлять файл listener.ora после создания каждой базы данных на сервере.
Для обеспечения возможности автоматической регистрации файл init.ora или SPFILE должен содержать следующие параметры:
Если значение параметра SERVICE_NAMES не указано, по умолчанию ему присваивается значение глобального имени базы данных, являющееся сочетанием параметров DB_NAME и DB_DOMAIN. Значение параметра INSTANCE_NAME, устанавливаемое по умолчанию — идентификатор SID, введенный во время установки Oracle или создания базы данных.
Состояние листенера на сервере можно проверить с помощью утилиты lsnrctl, как показано в листинге ниже. Вывод показывает длительность работы Listener Oracle и размещение файла конфигурации службы слушателя. Он содержит также имена баз данных, которые слушатель “прослушивает” на предмет запросов на подключение.
Состояние в разделе Services Summary (Сводка по службам) листинга выше может принимать одно из следующих значений:
Команды TNS Listener Oracle
После вызова утилиты lsnrctl помимо status можно выполнять и другие важные команды. Например, команда services позволяет выяснить, какие службы слушатель отслеживает на предмет запросов на подключение.
На заметку! Состояние службы листенера можно проверить из страницы Net Services Administration (Администрирование сетевых служб) в Oracle Enterprise Manager.
Ознакомиться с доступными командами утилиты lsnrctl можно с помощью команды help, введенной в интерфейсе lsnrctl, как показано в листинге ниже.
После вызова утилиты lsnrctl запуск Listener можно осуществить с помощью команды start, а его остановку — с помощью команды stop. Если эти команды требуется выдать из командной строки операционной системы, можно использовать команды lsnrctl start и lsnrctl stop.
При внесении изменений в файл listener.ora единственный способ ввода этих изменений в действие — перезапуск слушателя. Другой, более безопасный способ — просто перезагрузка информации Listener, в результате чего последние выполненные изменения слушателя будут внесены в файл конфигурации. Команда lsnrctl reload позволяет перезагрузить TNS Listener Oracle “на лету”, без его перезапуска. Подключенные в текущий момент клиенты останутся подключенными во время перезагрузки Listener (или даже при его перезапуске), поскольку слушатель уже “отдал” подключения базе данных и не участвует в обмене данными между клиентом и службой базы данных.
Внимание! Изменять файл listener.ora не рекомендуется, если только для этого не существует веской причины. Кроме того, при использовании динамической автоматической регистрации служб необходимость в модификации файла возникает значительно реже. Тем не менее, в некоторых случаях приходится изменять определенную часть файла Listener, содержащую информацию о конфигурации сети для всех служб, которые слушатель отслеживает на предмет запросов подключения.
Управление Listener
Хотя установка службы Listener Oracle достаточно проста, после ее выполнения можно предпринять ряд действий для более точной настройки процесса подключения и для обеспечения безопасности службы TNS Listener Oracle. Некоторые из этих параметров описаны в последующих разделах.
Несколько TNS Listener
На одном сервере могут действовать более одной службы Listener NET Oracle, но обычно такую конфигурацию придется применять в Oracle RAC. При использовании нескольких служб слушателя можно конфигурировать параметр CONNECT_TIME_FAILOVER, который определяет длительность ожидания клиентом подключения через одного Listener, прежде чем будет предпринята попытка подключения с помощью другого Listener Oracle.
Установка размера очереди
Иногда большое количество одновременных запросов на подключение со стороны клиентов могут перегрузить службу слушателя. Чтобы уберечь Listener от сбоя, можно использовать параметр QUEUESIZE в файле конфигурации listener.ora для указания допустимого количества параллельно выполняющихся запросов на подключение.
Для большинства операционных систем значение параметра QUEUESIZE — достаточно небольшое число, наподобие 5. Ниже приведен пример установки параметра QUEUESIZE:
Установка пароля для Oracle Listener
При первоначальной установке Listener утилита не имеет никакой защиты паролем. Любой пользователь, имеющий доступ к операционной системе, без труда может остановить Listener Oracle и воспрепятствовать клиентам подключаться, просто введя команду lsnrctl stop в командной строке.
На заметку! Установленный по умолчанию пароль службы слушателя — listener, и при использовании Listener этот пароль указывать не нужно.
Собственный пароль для утилиты Listener Oracle можно установить, как показано в листинге ниже.
После того как пароль успешно изменен, службу Listener нельзя будет останавливать или запускать как раньше — для этого придется ввести пароль пользователя. Для указания листенеру Оракл нового пароля необходимо использовать выражение set password в приглашении утилиты lsnrctl, после чего можно еще раз запустить или остановить службу Oracle Net Listener. Обратите внимание, что выражение set password не устанавливает новый пароль, а просто вынуждает слушателя запрашивать пароль для выполнения административных задач.
Результат неудачной попытки остановки Listener вследствие отсутствия предоставленного пароля показан в листинге ниже. Затем листенер был корректно остановлен посредством применения команды set password.
Атака на оракула. Подробный гайд по векторам атак на Oracle DB
Сегодня я бы хотел поговорить о векторах атак на СУБД Oracle на разных стадиях: как прощупать слабые места базы снаружи, проникнуть и закрепиться внутри плюс как все это дело автоматизировать с помощью специализированного софта. Архитектура и возможности базы данных весьма интересны, занимательных моментов немало, а значит, немало и способов все испортить. Однако не забывай: ломать — не строить, поэтому вся дальнейшая информация предоставлена исключительно с целью выявить недочеты в защищенности тестируемых систем и повысить безопасность.
Внешний периметр. The listener is under attack
Кто хоть раз сталкивался с этой базой данных, знает, что взаимодействие с Oracle RDBMS осуществляется через TNS Listener. Listener — это своего рода балансировщик подключений. По умолчанию listener слушает 1521-й TCP-порт (в «будущем» Oracle обещает перейти на 2483 и 2484/SSL) и разруливает входящие подключения в зависимости от того, какая запрошена БД, что, соответственно, позволяет работать с несколькими. Идентификация конкретной базы данных происходит на основании буквенно-цифровой строки — ее SID’а (System IDentifier). Есть также понятие SYSTEM_NAME, которое чаще всего можно воспринимать как аналог SID (с пентестерской точки зрения, конечно).
Именно с атак на службу listener, как правило, начинается пентест базы данных Oracle. С задачей нахождения и определения версии СУБД отлично справляется Nmap. Но первым делом для нас важно получение SID для подключения к «листенеру», ведь без него listener не станет с нами общаться. На эту тему Sh2kerr когда-то написал отличное исследование Different ways to guess Oracle database SID.
К основным методам получения SID можно отнести перебор типовых значений для конкретной платформы, так как SID может быть дефолтным. Например, ORCL — по умолчанию для обычного Oracle, XE — для версии Oracle Express Edition. Также SID может быть получен через сторонние ресурсы. Например, веб-интерфейс EM-консоли на 1158-м порту; через SAP web_appserver, XDB и прочие штуки, установленные поверх Oracle. Системный идентификатор можно пробрутить, так как listener при подключении возвращает различные ошибки в зависимости от того, существует такой SID или нет. К тому же есть давняя практика делать короткие идентификаторы (3–4 символа). При переборе не стоит забывать про название компании, название системы, имена хостов и прочие социальные аспекты. С последней задачей весьма эффективно справляется модуль из Метасплоита auxiliary/scanner/oracle/sid_brute. Для атаки достаточно указать IP-адрес удаленного хоста. Это весьма неплохая брутилка сидов, она имеет встроенный словарик на 600 типовых значений.
Кстати, встретить Oracle версии ниже 10.0 — настоящий праздник для пентестера. Listener одной из старых версий с настройками по умолчанию раскрывает все что можно, включая обслуживаемые SID, версию СУБД, тип ОС, и имеет еще ряд важных уязвимостей (здесь и далее мы используем утилиту lsnrtctl, которая входит в комплект Oracle):
Для реальной атаки мы воспользуемся утилитой tnscmd.pl, так как lsnrctl не может посылать кастомные запросы. Первым запросом указываем в качестве лога bat в автозагрузке, вторым добавляем пользователя:
Еще раз подчеркну, что эти атаки актуальны лишь для Oracle до десятой версии. Начиная с «десятки», удаленная конфигурация по умолчанию запрещена. Хотя немного информации из дисклоза мы получить все-таки можем.
Внешний периметр. TNS Listener Poison
Если ты встретил версию «листенера» посвежее, то тут уже особо не разгуляться, остается только брутфорс. Впрочем, все версии, включая 12c, с настройками по умолчанию уязвимы к атаке под названием TNS Listener Poison (разновидность техники «человек посередине», MITM). Правда, 12c уязвима лишь в некоторых конфигурациях. К примеру, один из вариантов, которые могут нам помешать, — это отключение динамического конфигурирования «листенера», что невозможно при использовании Oracle DataGuard, PL/SQL Gateway с подключением в APEX и некоторых версий SAP.
Дело тут вот в чем: по умолчанию сервис «листенера» поддерживает удаленное конфигурирование, необходимое для создания кластера базы данных (RAC — Real Application Cluster). Фактически мы можем подключиться к «листенеру» и «зарегистрироваться», то есть сказать ему, что мы член кластера, на котором работает его база данных. Дальше можно ждать подключений от клиентов, которые нам будет перекидывать listener. Но не всех, а только части, потому что listener балансирует нагрузку на кластер: кого-то сразу подключит к настоящей СУБД, кого-то отправит нам. При этом для полноценной MITM-атаки никто не мешает перенаправлять подключающихся к нам клиентов обратно в СУБД. И при этом у нас будет возможность полностью контролировать передаваемый трафик: и просматривать его (данные, не считая аутентификации, не шифруются), менять команды и добавлять их.
Принцип эксплуатации уязвимости TNS Poison
Вот примерный алгоритм атаки:
Архив со скриптами (proxy, poisoner) и сверхподробное описание уязвимости.
Внешний периметр. Users Brute force
Получил SID? Отлично, переходим к следующей типичной задаче — добываем учетку. С этого момента мы можем подключаться к «листенеру» и брутить учетные записи. Вообще, Oracle некогда был уязвим, и можно было сначала брутить логины, а потом пароли (та же проблема: различные ошибки для существующих и несуществующих пользователей), но имеющиеся тулзы стары и работают очень нестабильно. С классическим же перебором учеток снова выручает Metasploit и его модуль `auxiliary/scanner/oracle/oracle_login`. Он имеет встроенный словарик наиболее популярных дефолтных учеток в виде login:password. Хотя, конечно, он не покрывает всех возможных вариаций, и иногда приходиться гуглить инфу про ломаемую платформу или задумываться на тему фантазии сотрудников и снова брутить. При этом не стоит забывать, что Oracle поддерживает парольные политики и может заблокировать учетные записи.
Дефолтные записи представляют одну из самых распространенных и одновременно серьезных проблем безопасности в «Оракуле». Этих пользователей немало, они имеют различные привилегии, и некоторые из них не так-то просто отключить. Так что, проводя аудит безопасности продуктов Oracle, очень важно посмотреть в документации список учетных записей по умолчанию. Причем если в «чистой» Oracle DB подобных записей не так много, то, если на нее поставить ERP-систему вроде E-Business Suite, их становится около 300! Для более тщательного, но и длительного брутфорса советую обратиться к Nmap:
Учти, что этот скрипт перемешивает логины и пароли, то есть к каждому логину пробует каждый пароль, а это довольно долго!
Внешний периметр. Remote OS Auth
Несколько более изящный способ добыть себе учетку от базы — обойти проверку. Но это сработает, только если в тестируемой системе используется `Remote OS Auth`. Суть в том, что в Oracle RDBMS есть возможность перекладывать аутентификацию пользователя на плечи ОС. Таким образом, если пользователь аутентифицирован в ОС, то подключение к БД произойдет без проверки пароля. Логины таких пользователей в базе имеют префикс ops$ (например, ops$Bob). Причем эта функция работает и с удалёнными хостами. Таким образом, для атаки мы должны подключиться к «листенеру» с именем юзера и «сказать», что пароль проверен в ОС, так что нас можно пустить. Listener поверит и пустит :). Несмотря на кажущуюся странность, такой метод используется для связки SAP-систем c Oracle в качестве основного. Значит, практическая последовательность такова:
Кстати, пароль у пользователя в ОС и пароль у пользователя Oracle DB может отличаться, это ни на что не влияет.
На ZeroNights 2015 Роман Бажин (@nezlooy) поделился интересным наблюдением: оказалось, что в момент отправки пакета с запросом на авторизацию **можно подменить значение текущего пользователя**, а следовательно, можно устроить перебор. Сработает такая атака явно быстрее, нежели прямой брутфорс учеток, ведь нужно проверить лишь логины, без паролей. Подробнее про Remote OS Auth можно почитать тут и тут.
Внешний периметр. Remote stealth pass brute force
Еще одна серьезная уязвимость, которая была в Oracle RDBMS, — возможность удаленно получить хеш-пароль любого пользователя, а потом его локально пробрутить. К данной технике уязвимы версии 11.1.0.6, 11.1.0.7, 11.2.0.1, 11.2.0.2 и 11.2.0.3. Для того чтобы понять суть уязвимости, нужно рассмотреть, как работает протокол аутентификации с СУБД для одиннадцатой версии (маньяки из Oracle в каждой новой ветке меняют протокол аутентификации). Взаимодействие с сервером происходит по следующей схеме:
Внутренние атаки. Remote Code Execution
Так уж вышло, но добиться исполнения команд операционной системы в Oracle не так тривиально, как вызвать xp_cmdshell в MS SQL, даже если имеются привилегии DBO. Однако есть как минимум два отличных способа выполнения команд — использование Java-процедур и применение пакета DBMS_SCHEDULER. Кстати говоря, получить RCE можно и в случае нахождения SQL-инъекции в веб-приложении, разумеется, если у пользователя, от имени которого оно запущенно, хватает прав. Настоятельно рекомендую на данном этапе подготовить утилиту Oracle Database Attacking Tool ODAT. Не забудь установить необходимые библиотеки Python для работы с Oracle, а также сам Instant Client.
Итак, представим, что мы имеем админскую учетку. Весьма популярный способ исполнить свою команду на сервере в данном случае — написать процедуру `java stored`. Делается это в три этапа. Первый — создание Java-класса с именем oraexec. Для этого подключаемся через терминал sqlplus и пишем:
Далее напишем PL/SQL-обертку для этого класса:
Все! Теперь для выполнения достаточно отправить следующий запрос:
Важный нюанс: используя приведенную выше процедуру, мы не сможем увидеть результат отработанной команды, однако ничто не мешает перенаправлять вывод в файл и считывать его. Полный код этого шелла с возможностью считывания и записи файлов ты найдешь тут. Однако есть более навороченный скрипт, с обработкой вывода команд, правда и размер больше. Если применять для этой же цели утилиту ODAT, все действия сокращаются до следующей команды:
Внутренние атаки. Scheduler
Следующий способ, который выручит нас в случае отсутствия виртуальной машины Java (что свойственно Oracle Express Edition/XE), — это обращение к встроенному планировщику заданий Oracle `dbmsscheduler`. Для работы с ним необходимо иметь привилегию `CREATE EXTERNAL JOB`. Вот пример кода, который записывает строку 0wned в текстовый файл в корне диска C:
В результате будет создано, а затем исполнено задание по выполнению нашей команды. Еще один интересный момент заключается в том, что в основном multi-statement-запросы (то есть сложные запросы, состоящие из простых, разделенных точкой с запятой) не разрешены при работе с Oracle из внешних (то есть работающих через jdbc) приложений. Но есть такие процедуры, внутри которых можно исполнять «новые запросы», в том числе и multi-statement.
Пример такой процедуры — `SYS.KUPP$PROC.CREATE_MASTER_PROCESS`. Скажем, просто используя планировщик RCE, нельзя провести SQL-инъекцию, так как для нее требуется создание анонимной процедуры. А вот вместе с указанной выше процедурой уже можно. Таким образом, следующий запрос теоретически можно выполнить и в случае SQL-инъекции в веб-приложении.
ODAT.py вновь позволяет существенно сократить объем команд:
При использовании планировщика наше задание может выполняться не единожды, а с некоторой периодичностью. Это поможет закрепиться в тестируемой системе, поскольку, даже если администратор удалит пользователя из ОС, наше задание будет регулярно выполняться в системе и вновь вернет его к жизни.
Внутренние атаки. External tables
В качестве последнего способа добиться OS command execution я бы хотел описать внешние таблицы (External Tables). Этот же способ поможет далее скачивать файлы с сервера. Нам потребуются следующие привилегии:
Шаг первый: проверить выданные нам директории следующим запросом:
Шаг второй: создать исполняемый bat-файл с нужной нам командой:
Шаг третий: подготовим внешнюю таблицу `EXTT`, она нужна для запуска файла:
Теперь нам остается лишь вызвать наш батник следующей командой:
Терминал начнет выкидывать ошибки о невозможности сопоставить таблицу и вызываемый файл. Но в данном случае это неважно, ведь нам было нужно, чтобы открылся исполняемый файл, это и произошло. Утилита ODAT.py тоже умеет выполнять данную атаку, однако требует привилегию `CREATE ANY DIRECTORY` (она по умолчанию есть только у роли DBA), поскольку пытается исполнить файл из любой, а не из «нашей» директории:
Внутренние атаки. Работа с файловой системой
Переходим к задачке о чтении и записи файлов. Если необходимо просто считать файл или записать его на сервер, то можно обойтись и без Java-процедур, которые, впрочем, тоже справляются с такого рода тасками. А обратимся мы к пакету `UTL_FILE`, который обладает требуемым функционалом работы с файловой системой. Приятная новость — по умолчанию доступ к нему имеют все пользователи, обладающие ролью `PUBLIC`. Плохая новость — по умолчанию у этой процедуры нет доступа ко всей файловой системе, только к заранее заданному администратором каталогу. Впрочем, нередко встречается заданный параметр каталога *, что буквально означает «доступ ко всему». Уточнить это поможет следующая команда:
Расширить доступ, при наличии соответствующих прав можно следующим запросом:
Наиболее короткий вариант процедуры, применяющей пакет `UTL_FILE`, я подсмотрел у Александра Полякова:
Если требуется более функциональный вариант, с возможностью записи, рекомендую погуглить скрипт под названием raptor_oraexec.sql. И по традиции, вариант с применением утилиты ODAT, который, как всегда, самый короткий:
Пакет `UTL_FILE` весьма интересен еще и потому, что если повезет, то можно добраться до логов, конфигурационных файлов и раздобыть пароли от привилегированных учетных записей, например `SYS`.
Второй способ, о котором я бы хотел рассказать, — это вновь применить `External Tables`. Напомню: используя External Tables, база имеет возможность получить в режиме чтения доступ к данным из внешних таблиц. Для хакера это означает еще одну возможность выкачивания файлов с сервера, однако этот способ требует `CREATE ANY DIRECTORY` привилегию. Предлагаю сразу обратиться к ODAT, работает стабильно и быстро:
Внутренние атаки. Повышение привилегий
Повысить привилегии можно разными способами, начиная от классических переполнений буфера и патчинга DLL и заканчивая специализированными атаками для баз данных — PL/SQL-инъекциями. Тема очень обширная, в этой статье я не буду подробно останавливаться на ней, про это пишут отдельные исследования: о них можно почитать в блогах Личфилда и Финнигана. Покажу лишь некоторые из них, для общего представления. В ходе проведения тестирования советую просто обращать внимание на текущие привилегии и, уже отталкиваясь от этого знания, искать в интернете нужные лазейки.
В отличие от MS SQL, где атакующий может внедрить xp_cmdshell буквально сразу после SELECT, просто закрыв его, Oracle RDBMS такие фокусы категорически не любит. По этой причине классические SQL-инъекции нам не всегда подходят, хотя можно выкрутиться и в этом случае. Мы будем рассматривать PL/SQL-инъекции — изменение хода выполнения процедуры (функции, триггера и прочих объектов) путем внедрения произвольных команд в доступные входные параметры. (с) Sh2kerr
Для того чтобы внедрить полезную нагрузку, необходимо найти функцию, в которой входящие параметры не фильтруются. Основная идея атаки заключается в следующем: по умолчанию, если не указано иного, процедура выполняется от имени владельца, а не запустившего ее пользователя. Иными словами, если нам доступна для выполнения процедура, принадлежащая учетке `SYS`, и мы сможем внедрить в нее свой код, то наш пейлоад тоже исполнится в контексте учетной записи `SYS`. Так бывает не всегда, встречаются и процедуры с параметром authid current_user, а это означает, что процедура будет исполнена с привилегиями текущего пользователя. Впрочем, обычно под каждую версию СУБД можно найти функции, уязвимые к PL/SQL-инъекции.
Упрощенный вид PL/SQL Injection
Короче говоря, вместо ожидаемого честного аргумента мы передаем зловредный код, который становится частью процедуры. Хороший пример — это функция `CTXSYS.DRILOAD`. Она выполняется от имени `CTXSYS` и не фильтрует входящий параметр, что позволяет произвести легкий взлет до DBA:
Правда, это уже скорее история: уязвимость была найдена в 2004 году, и ей подвержены лишь старые версии — восьмые и девятые. Как правило, процесс эскалации привилегий разбивается на две части: написание процедуры, повышающей права, и собственно внедрение. Типовая процедура выглядит следующим образом:
Теперь можем внедрить процедуру в качестве аргумента уязвимой функции (пример для десятых версий):
В не слишком свежих версиях 10 и 11 есть приятное исключение, а точнее уязвимость, позволяющая исполнить команды на сервере, не обладая DBA-правами. Процедура `DBMS_JVM_EXP_PERMS` позволяет пользователю с привилегией `CREATE SESSION` получить права `JAVA IO`. Реализуется атака следующим образом:
Теперь, получив привилегии на вызов Java-процедур, можем достучаться до интерпретатора Windows и выполнить что-нибудь:
Полезные команды для начинающего DBA
Подключаемся к базе:
Показать текущего юзера:
Вывести всех пользователей:
Показать таблицы, принадлежащие пользователю:
Подводим итоги
Рассмотренные векторы, разумеется, не единственные, ведь появляются и новые уязвимости, причем регулярно. Плюс для актуальных версий есть ряд уязвимостей «из коробки», которые в Oracle, похоже, не торопятся исправлять. Oracle RDBMS — мощная, но очень сложная вещь, а потому подход «не трогай, если работает» очень распространен в компаниях. Это, безусловно, помогает при взломах.
Oracle версии 12 в статье вообще не рассматривался: во-первых, слишком мало шансов встретить его в реальной жизни, во-вторых, лучше рассказать про эту версию отдельно, так как многие базовые вещи в ней кардинально изменились. Вообще, в момент проведения тестирования вариантов того, как будут развиваться события, достаточно много. Необходимо отталкиваться от текущей стадии: где ты находишься относительно базы (внутри или снаружи), какие у тебя привилегии, какие цели, и дальше уже строить план прорыва. Надеюсь, общий подход понятен и стало ясно, что следует проверить на доступных тебе СУБД Oracle. Береги свои серверы!
