Как расширить атаку через Oracle-линки

РЕШЕНИЕ

Представь себе ситуацию: нашел ты SQL-инъекцию в веб-приложении или же подобрал учетку через TNS listener, то есть получил доступ к ораклу на бэкенде. Конечно, первым делом надо порыскать по доступным табличкам и слить все интересное, но потом всегда есть желание проникнуть «глубже» и добраться до ОС или других серверов, например. В общем, так называемый этап постэксплуатации. Конечно, здесь важный шаг — посмотреть привилегии пользователя и уже танцевать от них. Но мы сейчас сконцентрируемся на одном из методов — через связи (они же «db link’и»),

Насколько я помню, все мощные СУБД, будь то Oracle, MS SQL, Postgres, имеют возможность сами подключаться к другим базам данных и вынимать инфу из них. Ты подключаешься в одну базу А и говоришь ей подключиться к СУБД Б, а дальше можешь посылать запросы через А в базу данных на Б. И что еще полезнее — данные можно «смешивать», то есть база данных А может выдавать различные итоги в зависимости отданных, полученных с Б.

«Обычный» юзер Oracle (созданный с ролями connect и resource, как это обычно происходит) не имеет прав на создание линков. Но это справедливо для версий с 10g R2 и более поздних. В более ранних версиях привилегия на создание линка входила в роль connect. Но что, если необходимые права у нас есть? Тогда мы можем сделать многое...

Представь себе ситуацию (причем вполне типовую): есть корпоративная сеть и в ней интересующая нас критичная система. Пусть это будет ERP. Но, как это бывает в здравомыслящих компаниях, ERP располагается в специальном сетевом сегменте с приличной фильтрацией, а наружу торчит только какой-нибудь веб-портал. Печалька... Но очень часто гораздо в меньшей строгости «живут» девелоперская версия той же ERP и версия ERP для тестирования. Кстати, такие тройки: боевая версия (продакшен), предпродакшен (тестирование) и девелоперская версия ERP — типовое решение в компаниях для любых крупных систем, так как они постоянно допиливаются, да и тестировать их надо.

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

Немного практики. Просмотр привилегий:

SELECT * FROM USER_SYS_PRIVS;

Просмотр ролей:

SELECT * FROM USER_ROLE_PRIVS;

Создание линка:

CREATE DATABASE LINK link_name USING @ORCL;

Здесь мы создаем линк с именем link_name к базе данных на том же хосте, с другим SID’om — ORCL (точнее service name’ом). При этом используется тот же логин и пароль, что и у действующего юзера.

Чтобы сказать базе данных, что данные мы хотим «переслать» в линк, мы должны указывать имя после собаки. Типа @link_name. Причем линк нужно указывать у имени таблицы. Например, запрос данных с удаленного сервера:

SELECT * from table_name(g)link_name;

Если же надо выполнить какую-то функцию на удаленном сервере, то линк нужно писать после имени функции, но до параметров:

SELECT function_name@link_name(function,parameters) from dual;

Кроме локальных линков, ты можешь создавать и удаленные, и даже с другими кредами:

CREATE DATABASE LINK link_name CONNECT TO username IDENTIFIED
BY password USING '//remote_host_name_or_ip:1521/ORCL;

Тут, думаю, ясно, что username и password — креды для подключения, a ORCL — это опять-таки service name.

И еще tip для удаления линков. Пригодится, чтобы подчищать хвосты.

DROP DATABASE LINK link_name;

Теперь давай прикинем, что мы можем сделать из этой возможности.
1. При создании локального линка ты сразу получишь ответ — есть такой SID или нет. При удаленном линке после первого запроса по линку получаешь аналогичный ответ. Причем в случае существования SID’a проверяются логин и пароль и система также возвращает ошибку, если они неверны. Таким образом, мы можем спокойно сначала перебирать SID’ы, а потом уже стандартные или не очень учетки.

2. Можно подключиться к самому же себе, но под другой учеткой! Это не так актуально для доступа через TNS, но вот для SQL-инъекций — самое то. Приведу пример. Есть SQLi в приложении, и мы можем выполнять какие-то запросы от какого-то юзера. Но у него может не быть интересных нам прав. А потому мы берем и создаем линк в ту же базу данных, но с другими кредами (брутфорс нам поможет). И вуаля! Мы все там же — за веб-приложением, но уже имеем в базе данных гораздо больше прав. Магия практически. Но здесь есть одно обидное ограничение. Для линков нет возможности создавать привилегированные подключения (под SYSDBA), что в зависимости от версии оракла может нас сильно (или не очень) ограничить в возможностях.

3. Когда ты получил доступ в базу данных — посмотри, нет ли там уже созданных линков. Шанс невелик, но все возможно. Причем, во-первых, там могут быть линки, уже созданные под твоим же юзером кем-то ранее, а бывают еще общие (PUBLIC) линки, созданные под каким-то другим пользователем, но доступные всем. Все доступные юзеру линки:

select * from USER_DB_LINKS;

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

5. После небольшого ресерча оказалось, что мы можем проводить SSRF-атаки. Есть ряд обидных ограничений. Во-первых, мусор в несколько строк в начале (бинарные заголовки от TNS-протокола), во-вторых, в некоторых запрещенных символах. Ну и да, ответ от сервера нам не получить. Зато мы можем делать перенос строк, а потому вполне можем общаться с различными плейнтекстовыми протоколами. FTP, SMTP... Вероятно, против memcached заработает. В указанном выше способе создания линка наши команды идут после ORCL и до закрывающей кавычки.

6. И еще один «итог» SSRF — NTLM-релей. Мы можем указать линк на себя, перехватить NTLM-аутентификацию и переслать ее на другой сервер. Фичу эту я до конца не проверил, но к выходу журнала будет готовый PoC.