Форум АНТИЧАТ - [Перевод]Анатомия Oracle:Часть 3.Поиск доказательств атак на механизм аутентификации

[Перевод]Анатомия Oracle:Часть 3.Поиск доказательств атак на механизм аутентификации

25.01.2008, 01:43

NeMiNeM

Постоянный

Регистрация: 22.08.2005

Сообщений: 540

Провел на форуме:
4372175

Репутация: 1221

[Перевод]Анатомия Oracle:Часть 3.Поиск доказательств атак на механизм аутентификации

Автор: David Litchfield [davidl@ngssoftware.com]
Дата: 27 марта 2007
Перевод: NeMiNeM
www.antichat.ru

В этой части мы рассмотрим атаки на механизм аутентификации и свидетельства с лог-файла TNS-слушателя и журнала аудита, с помощью аудита CREATE SESSION; мы также увидим был ли вход в систему удачный или нет; разберем атаки на процесс аутентификации, включая угадывание SID, перебор пользователей и брут форс паролей. Изучим отличия между входом в систему через FTP и Web-сервисы с базой данных XML или РСУБД.

[Обнаружение попыток получить SID (идентификатор службы)]

Чтоб войти в РСУБД, атакующий должен знать идентификатор бд (SID). До выпуска Oracle 10g об этом можно было узнать с помощью TNS-слушателя и команды SERVICES или STATUS.

Пример содержимого лог-файла после попытки кем-то собрать информацию:

Код:

… 
16-MAR-2007 13:02:31 * 
(CONNECT_DATA=(CID=(PROGRAM=)(HOST=)(USER=DAVID))(COMMAND=services)(A
RGUMENTS=64)(SERVICE=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=192.16
8.1.100)(PORT=1521))))(VERSION=169869824)) * services * 0 
… 
… 
16-MAR-2007 13:02:32 * 
(CONNECT_DATA=(CID=(PROGRAM=)(HOST=)(USER=DAVID))(COMMAND=status)(ARG
UMENTS=64)(SERVICE=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.1.100)(PORT=1
521)))(VERSION=169869824)) * status * 0 
…

Заметьте, что IP не атакующего, а сервера, т.е. это нам неважно. Строка VERSION - 169869824, что в hex составляет 0xA200200. Это указывает на версию софта клиента - 10.2.0.2.0 - может нам понадобиться позже. Заметьте, эта величина полностью под контролем клиента и необязательно должна быть верной. Например, атакующий может написать свой собственный клиент Oracle, перехватить и подменить эти значения. Мы также видим имя пользователя “DAVID”(имя учётной записи в его OS - опять же, это значение полностью под контролем атакующего). Мы вернемся к этому через минутку.

[Брутфорс Идентификаторов сервиса. (SID)]

Как уже говорилось, начиная с версии 10g, атакующему не так просто получить SID. Один с методов это попробовать брутфорс атаку. В Сети много инструментов, которые это делают (sidgusser.exe от CQure.net, sidguess.exe от Red Database Security и orabrutesid.exe от DatabaseSecurity.com)

Пример лог-файла TNS-слушателя после использования sidguesser.exe от cqure.net.

Код:

25-MAR-2007 20:03:54 * 
(CONNECT_DATA=(SID=WINDOWS901)(CID=(PROGRAM=)(HOST=__jdbc__)(USER=))) 
* (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.1.64)(PORT=2145)) * establish 
* WINDOWS901 * 12505 
TNS-12505: TNS:listener does not currently know of SID given in 
connect descriptor 
25-MAR-2007 20:03:54 * 
(CONNECT_DATA=(SID=WINDOWS902)(CID=(PROGRAM=)(HOST=__jdbc__)(USER=))) 
* (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.1.64)(PORT=2146)) * establish 
* WINDOWS902 * 12505 
TNS-12505: TNS:listener does not currently know of SID given in 
connect descriptor 
25-MAR-2007 20:03:54 * 
(CONNECT_DATA=(SID=WINDOWS9021)(CID=(PROGRAM=)(HOST=__jdbc__)(USER=))
) * (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.1.64)(PORT=2147)) * 
establish * WINDOWS9021 * 12505 
 
TNS-12505: TNS:listener does not currently know of SID given in 
connect descriptor

Sidguesser.exe создает свои собственные TNS пакеты и прописывается как будто клиент использует JDBC.
Мы конечно "знаем", что это был sidguesser.exe от cqure.net, но в реальности мы сможем только сказать, что лог соответствует сигнатуре инструмента. Например, атакующий возможно создал свой собственный переборщик SID'ов используя JDBC и мы увидим в логе тоже самое что и в случаи с sidguesser.

А вот такое содержимое лог-файла мы увидим после использования sidguess.exe от Red-Database-Security.

Код:

25-MAR-2007 19:52:30 * 
(CONNECT_DATA=(SID=ORA8)(CID=(PROGRAM=C:\backup\sidguess.exe)(HOST=AP
OLLO)(USER=david))) * 
(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.1.64)(PORT=4333)) * establish * 
ORA8 * 12505 
TNS-12505: TNS:listener does not currently know of SID given in 
connect descriptor 
25-MAR-2007 19:52:30 * 
(CONNECT_DATA=(SID=ORA805)(CID=(PROGRAM=C:\backup\sidguess.exe)(HOST=
APOLLO)(USER=david))) * 
(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.1.64)(PORT=4334)) * establish * 
ORA805 * 12505 
TNS-12505: TNS:listener does not currently know of SID given in 
connect descriptor 
25-MAR-2007 19:52:30 * 
(CONNECT_DATA=(SID=ORA806)(CID=(PROGRAM=C:\backup\sidguess.exe)(HOST=
APOLLO)(USER=david))) * 
(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.1.64)(PORT=4335)) * establish * 
ORA806 * 12505 
TNS-12505: TNS:listener does not currently know of SID given in 
connect descriptor

Этот инструмент использует клиентские библиотеки Oraclе и передает "дополнительную" информацию в лог-файл - имя хоста клиента (APOLLO) и учётная запись в OSи атакующего - "DAVID". И опять же, не стоит рассчитывать на эту информацию, поскольку она может быть модифицирована атакующим.

Содержимое лог-файла после orabrutesid.exe (www.databasesecurity.com).

Код:

25-MAR-2007 20:38:43 * (CONNECT_DATA=(SID=2P)) * 
(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.1.64)(PORT=4051)) * establish * 
2P * 12505 
TNS-12505: TNS:listener does not currently know of SID given in 
connect descriptor 
25-MAR-2007 20:38:43 * (CONNECT_DATA=(SID=3P)) * 
(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.1.64)(PORT=4052)) * establish * 
3P * 12505 
TNS-12505: TNS:listener does not currently know of SID given in 
connect descriptor 
25-MAR-2007 20:38:43 * (CONNECT_DATA=(SID=4P)) * 
(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.1.64)(PORT=4053)) * establish * 
4P * 12505 
TNS-12505: TNS:listener does not currently know of SID given in 
connect descriptor

Этот инструмент создает собственные TNS пакеты и заметим, что он передает очень мало "дополнительной" информации. Как мы уже писали, эта информация находится под контролем клиента и он может переслать любую. Отсутствие информации - это и есть как бы "сигнатура" этого инструмента.

[Обнаружение атак на перебор имен учётных записей]

В процессе аутентификации, клиент вводит своё имя пользователя, которое передается серверу одним пакетом. Если оно существует в БД - сервер выдает ключ сессии и клиент отсылает зашифрованный пароль другим пакетом. Если пользователь не существует, сервер отсылает ошибку: ORA-01017: invalid username/password;logon denied. Таким образом, атакующий может узнать существует ли учетная запись или нет. (Пожалуйста, заметьте, это уже исправили в некоторых версиях). Поскольку клиент должен отправить только одни пакет, чтоб узнать существует запись или нет, полная аутентификация не проходит. Как же это всё выглядит в журнале аудита? Опять же, всё зависит от того, существует учетная запись или нет.

Если нет - то в журнале аудита создается запись с кодом возврата 1017:

Код:

SQL> SELECT USERID, ACTION#, RETURNCODE, TIMESTAMP# FROM SYS.AUD$; 

USERID              ACTION# RETURNCODE TIMESTAMP# 
------------------- ------- ---------- ------------------- 
NOSUCHUSER0         100     1017       2007-03-25 23:42:38 
NOSUCHUSER1         100     1017       2007-03-25 23:42:38 
NOSUCHUSER2         100     1017       2007-03-25 23:42:38 
NOSUCHUSER3         100     1017       2007-03-25 23:42:38 
NOSUCHUSER4         100     1017       2007-03-25 23:42:39

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

В столбце COMMENT$TEXT есть IP адрес, с которого была попытка войти в систему:

Код:

SQL> SELECT USERID, COMMENT$TEXT FROM SYS.AUD$; 

USERID       COMMENT$TEXT 
-------      ------------------------------------------------- 
NOSUCHUSER0  Authenticated by: DATABASE; Client address: (ADDRESS= 
(PROTOCOL=tcp)(HOST=192.168.1.64)(PORT=2223))

А что с лог-файлом TNS-слушателя? Что он нам расскажет об атаке? Его ответ зависит от инструмента, который использовался при атаке. Не всем известный факт, что не обязательно создавать новое TCP-соединение для каждой попытки аутентификации. При одном подключении, атакующий может сколько угодно перебирать имена записей. Нам известен только один инструмент, который использует тоже самое TCP-соединение - ora-brutesid.exe, часть Oracle Assessment Kit. Большинство инструментов не используют одно соединение и будет переподключаться к TNS-слушателю и зафиксируются множественными записями:

Код:

.. 
25-MAR-2007 23:42:38 * 
(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=orcl.databasesecurity.c
om)(CID= (HOST=APOLLO)(USER=david))) * 
(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.1.64)(PORT=1769)) * establish * 
orcl.databasesecurity.com * 0 
25-MAR-2007 23:42:38 * 
(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=orcl.databasesecurity.c
om)(CID= (HOST=APOLLO)(USER=david))) * 
(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.1.64)(PORT=1772)) * establish * 
orcl.databasesecurity.com * 0 
25-MAR-2007 23:42:38 * 
(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=orcl.databasesecurity.c
om)(CID (HOST=APOLLO)(USER=david))) * 
(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.1.64)(PORT=1774)) * establish * 
orcl.databasesecurity.com * 0 
25-MAR-2007 23:42:39 * 
(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=orcl.databasesecurity.c
om)(CID= (HOST=APOLLO)(USER=david))) * 
(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.1.64)(PORT=1776)) * establish * 
orcl.databasesecurity.com * 0 
25-MAR-2007 23:42:39 * 
(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=orcl.databasesecurity.c
om)(CID= (HOST=APOLLO)(USER=david))) * 
(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.1.64)(PORT=1778)) * establish * 
orcl.databasesecurity.com * 0 
..

Здесь мы можем увидеть множественные входы с 192.168.1.64 в краткий промежуток времени. Если задуматься, то не_факт что имел место перебор имен пользователей, мы просто видим повторяющиеся события. Но если, это всё объединить с логами с журнала аудита это будет выглядит более уверенно. Как мы уже писали, более "совершенный" инструмент не будет передпоключаться к слушателю и единственное свидетельство множественных несуществующих акков с журнала аудита - это всё, на что можно положиться.

[Атака-Перебор паролей]

Если у атакующего есть список пользователей он может попробовать угадать их пароли. Простой брутфорсер паролей будет создавать новое подключение для каждой новой попытки подбора и в лог-файле Слушателя каждая запись будет фиксироваться. Такая же ситуация как и с перебором имен пользователей.
Если мы опять посмотрим на логи то заметим, что запрос на обслуживание и порт подключения клиента увеличиваются на один. Это стандартное поведение при создании нового TCP-подключения. Хотя мы не можем с уверенностью на 100%, что такая запись - результат использования брут-форс атаки. Например, это может быть просто криво-настроенный сервер, который пытается войти с помощью неверного имени и пароля. IP-адрес в лог-файле должен указывать на то, "известен" ли нам хост.

Более продвинутый инструмент для брут-форса - orapwdbrute.exe от Oracle Assessment Kit’s(www.databasesecurity.com) - никогда не будет переподключаться для каждой попытки подбора пароля, как уже замечалось. Но есть одна странная вещь с orapwdbrute.exe - это то, как Oracle записывает код возврата в журнал аудита: 1005.
Этот код указывает, что:

Код:

ORA-1005: null password provided; logon denied

Похоже на то, что Oracle немножко "удивлен" множественными попытками входа с одного канала, да ещё и с такой скоростью - orapwdbrute.exe работает со скоростью 170 попыток в секунду, т.е. примерно 15 миллионов паролей в день - больше чем достаточно для перебора всех паролей длинной <5 символов.

Фрагмент с журнала аудита показывает код возврата 1005:

Код:

SQL> SELECT USERID, ACTION#, RETURNCODE, TIMESTAMP# FROM SYS.AUD$; 
.. 
SCOTT            100       1017 2007-03-27 02:50:17 
SCOTT            100       1017 2007-03-27 02:50:17 
SCOTT            100       1005 2007-03-27 02:50:17 
SCOTT            100       1005 2007-03-27 02:50:17 
SCOTT            100       1017 2007-03-27 02:50:17 
SCOTT            100       1017 2007-03-27 02:50:17

Другой полезный источник информации, который указывает на попытки брут-форса, особенно когда аудит выключен, это столбец LCOUNT таблицы USER$. Если блокировка учетной записи включена (в 10g по-умолчанию), то для каждой неудачной попытки, значение в этом столбце для пользователя со знаком вопроса увеличивается на 1.

Код:

SQL> SELECT NAME, LCOUNT FROM USER$ WHERE LCOUNT>0;

Количество попыток входа устанавливается пользователем в FAILED_LOGIN_ATTEMPTS. Если блокировка учетной записи включена, то LCOUNT не будет больше заданной границы.(например, если профиль позволяет на 10 неверных паролей, то LCOUNT будем максимум 10) Если учетная запись разблокирована, используя имя ALTER USER и команду ACCOUNT UNLOCK, тогда LCOUNT сбрасывается к 0. LCOUNT также будет 0 если пользователь успешно войдет в систему. Ну и наконец если значение FAILED_LOGIN_ATTEMPTS - UNLIMITED, тогда LCOUNT не изменится - оно всегда будет 0.

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

Код:

SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'YYYY-MM-DD HH24:MI:SS'; 

Session altered. 

SQL> SELECT NAME, LTIME FROM USER$ WHERE ASTATUS = 4; 

NAME                           LTIME 
------------------------------ ------------------- 
SCOTT                          2007-03-25 08:27:29

Даже если акк был разблокирован позже, LTIME покажет время, когда он был в последний раз заблокирован и это значение НЕ очищается так, как столбец LCOUNT.

[Брут форс SYS-записей]

Какая разница между попытками войти как SYS-пользователь с “AS SYSDBA” и как SYS-пользователь без “AS SYSDBA”? На первый взгял - небольшая - просто жонглирование flag-битами

Этот флаг байт указывает на запрашиваемый уровень привилегий при подключении. 6-ой бит устанавливается если подключаться как SYSDBA, а 7-ой если как SYSOPER. Даже если 6-ой или 7-ой бит не установлены, атакующий может попробовать войти в систему как SYS. Если пароль неправильный - получим ошибку ORA-01017: invalid username/password; logon denied .
Если правильный - получим ORA-28009: connection to sys should be as sysdba or sysoper.
Это различие позволяет атакующему узнать, что пароль был подобран правильно и есть возможность войти в систему “как sysdba”. Если “AS SYSDBA” или “AS SYSOPER” не указываются при попытки войти в систему - то запись создаётся в таблице AUD$.
Если попытка угадать пароль неудачна - код возврата будет 1017; если наоборот - 28009.
Если же атакующий установит уровень прав как SYSDBA или SYSOPER - журнал аудита это вообще не зафиксирует. Нам нужно искать свидетельства где-нибудь ещё. Дело в том, что если в Oracle доходит к привилегированным подключениям, то запись об этом создаётся в журнале событий ОС. В Виндовз это регистрационный журнал событий.

В *nix-ах эти сообщения передаются в syslog daemon. Если в логе ОС есть много записей с кодом 1017 это указывает на попытки брут-форса SYS-акков.

[Попытки использовать уязвимость AUTH_ALTER_SESSION]

Предположим, что у атакующего уже есть имя пользователя и пароль. Тогда он может использовать известную брешь на последней стадии аутентификации. Если имя и пароль были подтверждены системой, клиент выполняет команду ALTER SESSION. В ноябре 2005 Imperva независимо открыла брешь, раньше уже найденную Oracle, в процессе использования этой команды: она выполняется с правами SYS. Т.е. атакующий может изменить команду ALTER SESSION на GRANT DBA, которая потом успешно исполнилась бы. Эта уязвимость была пофиксена в июне 2006). Если аудит включен для CREATE SESSION, то у нас есть возможность увидеть попытки использовать эту брешь на пропатченых системах.
Если атакующий пытается выполнить любую SQL-команду, на которую у него нет прав, вот такая ошибку он увидит:

Код:

ORA-00604: error occurred at recursive SQL 
level 1. ORA-01031: insufficient privileges.

А вот такая запись с кодом возврата 604 появится в журнале аудита:

Код:

SQL> SELECT USERID, ACTION#, RETURNCODE, TIMESTAMP# FROM SYS.AUD$; 
---------------------- ----   ---   ------------- 
.. 
SCOTT                  100    604   26-MAR-07 
..

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

[Обнаружение попыток входа в систему через XML Database (XDB)]

БД XML предоставляет два сетевых сервиса - сервер FTP порт: 2100 и Web-server на TCP порту 8080. Практически TNS-слушатель держит эти порты открытыми и когда надходит запрос, он передает его к бд сервера. Хотя роль TNS-слушателя в этом и небольшая, но подключение всё же фиксируется в его лог-файле.
Если подключение идет к вэб-службе, мы увидим это:

Код:

25-MAR-2007 21:07:25 * http * handoff * 0

Если к FTP-сервису, то:

Код:

27-MAR-2007 03:07:46 * FTP * handoff * 0

Не очень много информации кроме даты и факта, что кто-то подключился. Мы не знаем кто и с какого IP-адреса, есть только время.
Если посмотрим в журнал аудита мы увидим тоже самое:

Код:

SQL> SELECT USERID, ACTION#, RETURNCODE, TIMESTAMP# FROM SYS.AUD$; 
.. 
DBSNMP            100          0 2007-03-27 03:07:46 
..

IP-адрес можно узнать с столбца COMMENT$TEXT, но если присмотримся, то здесь фактически нет отличий между обыкновенным входом в базу.

Код:

SQL> SELECT COMMENT$TEXT FROM SYS.AUD$ WHERE USERID = 'DBSNMP'; 

COMMENT$TEXT 
--------------------------------------------------------- 
Authenticated by: DATABASE; Client address: 
(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.1.64)(PORT=1324))

Пока это не ключевой довод - это можно подтвердить как XDB вход в систему, потому что, если мы возьмем столбцы TERMINAL и SPARE1 (хранит имя пользователя OS) - они пустые.

Код:

SQL> SELECT TERMINAL,SPARE1,TIMESTAMP# FROM SYS.AUD$ WHERE USERID= 
'DBSNMP'; 

TERMINAL     SPARE1     TIMESTAMP# 
-----------  ------     ---------- 
                        2007-03-27 03:07:46

Мы говорим, что это не довод,потому что вспомните - клиент сам выбирает, какую информацию передавать БД.