|
[Перевод]Анатомия 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. Пример содержимого лог-файла после попытки кем-то собрать информацию: Код:
… [Брутфорс Идентификаторов сервиса. (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 * Мы конечно "знаем", что это был sidguesser.exe от cqure.net, но в реальности мы сможем только сказать, что лог соответствует сигнатуре инструмента. Например, атакующий возможно создал свой собственный переборщик SID'ов используя JDBC и мы увидим в логе тоже самое что и в случаи с sidguesser. А вот такое содержимое лог-файла мы увидим после использования sidguess.exe от Red-Database-Security. Код:
25-MAR-2007 19:52:30 * Содержимое лог-файла после orabrutesid.exe (www.databasesecurity.com). Код:
25-MAR-2007 20:38:43 * (CONNECT_DATA=(SID=2P)) * [Обнаружение атак на перебор имен учётных записей] В процессе аутентификации, клиент вводит своё имя пользователя, которое передается серверу одним пакетом. Если оно существует в БД - сервер выдает ключ сессии и клиент отсылает зашифрованный пароль другим пакетом. Если пользователь не существует, сервер отсылает ошибку: ORA-01017: invalid username/password;logon denied. Таким образом, атакующий может узнать существует ли учетная запись или нет. (Пожалуйста, заметьте, это уже исправили в некоторых версиях). Поскольку клиент должен отправить только одни пакет, чтоб узнать существует запись или нет, полная аутентификация не проходит. Как же это всё выглядит в журнале аудита? Опять же, всё зависит от того, существует учетная запись или нет. Если нет - то в журнале аудита создается запись с кодом возврата 1017: Код:
SQL> SELECT USERID, ACTION#, RETURNCODE, TIMESTAMP# FROM SYS.AUD$; Откуда же была атака? Как нам это узнать? В столбце COMMENT$TEXT есть IP адрес, с которого была попытка войти в систему: Код:
SQL> SELECT USERID, COMMENT$TEXT FROM SYS.AUD$; Код:
.. [Атака-Перебор паролей] Если у атакующего есть список пользователей он может попробовать угадать их пароли. Простой брутфорсер паролей будет создавать новое подключение для каждой новой попытки подбора и в лог-файле Слушателя каждая запись будет фиксироваться. Такая же ситуация как и с перебором имен пользователей. Если мы опять посмотрим на логи то заметим, что запрос на обслуживание и порт подключения клиента увеличиваются на один. Это стандартное поведение при создании нового TCP-подключения. Хотя мы не можем с уверенностью на 100%, что такая запись - результат использования брут-форс атаки. Например, это может быть просто криво-настроенный сервер, который пытается войти с помощью неверного имени и пароля. IP-адрес в лог-файле должен указывать на то, "известен" ли нам хост. Более продвинутый инструмент для брут-форса - orapwdbrute.exe от Oracle Assessment Kit’s(www.databasesecurity.com) - никогда не будет переподключаться для каждой попытки подбора пароля, как уже замечалось. Но есть одна странная вещь с orapwdbrute.exe - это то, как Oracle записывает код возврата в журнал аудита: 1005. Этот код указывает, что: Код:
ORA-1005: null password provided; logon deniedФрагмент с журнала аудита показывает код возврата 1005: Код:
SQL> SELECT USERID, ACTION#, RETURNCODE, TIMESTAMP# FROM SYS.AUD$; Код:
SQL> SELECT NAME, LCOUNT FROM USER$ WHERE LCOUNT>0;Предпологая, что блокировка учетной записи включена, есть ещё немножко информации, которая поможет нам при расследовании атаки. Существует столбец с датой, который фиксирует, когда акк был заблокирован. Код:
SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'YYYY-MM-DD HH24:MI:SS'; [Брут форс SYS-записей] Какая разница между попытками войти как SYS-пользователь с “AS SYSDBA” и как SYS-пользователь без “AS SYSDBA”? На первый взгял - небольшая - просто жонглирование flag-битами:) http://i242.photobucket.com/albums/f...lipboard01.jpg Этот флаг байт указывает на запрашиваемый уровень привилегий при подключении. 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 доходит к привилегированным подключениям, то запись об этом создаётся в журнале событий ОС. В Виндовз это регистрационный журнал событий. http://i242.photobucket.com/albums/f...lipboard02.jpg В *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 Код:
SQL> SELECT USERID, ACTION#, RETURNCODE, TIMESTAMP# FROM SYS.AUD$; [Обнаружение попыток входа в систему через XML Database (XDB)] БД XML предоставляет два сетевых сервиса - сервер FTP порт: 2100 и Web-server на TCP порту 8080. Практически TNS-слушатель держит эти порты открытыми и когда надходит запрос, он передает его к бд сервера. Хотя роль TNS-слушателя в этом и небольшая, но подключение всё же фиксируется в его лог-файле. Если подключение идет к вэб-службе, мы увидим это: Код:
25-MAR-2007 21:07:25 * http * handoff * 0Код:
27-MAR-2007 03:07:46 * FTP * handoff * 0Если посмотрим в журнал аудита мы увидим тоже самое: Код:
SQL> SELECT USERID, ACTION#, RETURNCODE, TIMESTAMP# FROM SYS.AUD$; Код:
SQL> SELECT COMMENT$TEXT FROM SYS.AUD$ WHERE USERID = 'DBSNMP'; Код:
SQL> SELECT TERMINAL,SPARE1,TIMESTAMP# FROM SYS.AUD$ WHERE USERID= |
[Аудит системы отключен?]
Если же аудит отключен и вы используете Oracle 10g, доказательства входов в систему всё же можно найти. V$ACTIVE_SESSION_HISTORY использует кольцевой буфер в SGA, чтоб сохранять каждую секунду образцы информации об активных сессиях. Эти сессии передаются от SGA в таблицу WRH$_ACTIVE_SESSION_HISTORY очень часто, как часть Automatic Workload Repository(автоматический репоиторий нагрузки). Эти данные полезны исследователю, поскольку они эффективно записывают информацию о входах в систему. Код:
SQL> SELECT USER_ID, SESSION_ID, SAMPLE_TIME FROM При отсутствии информации аудита эти данные могут быть очень важные при расследовании атаки на систему. [Наконец то! Попался!] Когда пользователь успешно входит в систему в журнале аудита создается строка с номером ACTION# 100 (LOGON). Столбец TIMESTAMP# указывает на время входа в систему. Вот так это выглядит: Код:
SQL> SELECT USERID, ACTION#, RETURNCODE, TIMESTAMP# FROM SYS.AUD$; Код:
SQL> SELECT USERID, ACTION#, RETURNCODE, TIMESTAMP# FROM SYS.AUD$; Код:
SQL> select userid,action#,TIMESTAMP#,LOGOFF$TIME from aud$; У нас есть возможность найти свидетельства атак как в лог-файле TNS-слушателя, так и в журнале аудита. Мы также увидели, что разные инструменты оставляют разный след в системе. Внимательно анализируйте код ответа в журнале аудита. Множество записей 1017 (и возможно 1005) с ACTION# 100 и кодом возврата 0 указывают на удачную брут-форс атаку. Помните, что в Oracle есть много учетных записей и паролей по-умолчанию и они будут первой целью атакующего. Оригинал в формате pdf NeMiNeM Специально для antichat.ru ps: В статье/переводе возможны ошибки. Просьба не кричать, а спокойно указать и исправить :) Спасибо. ============================ Другие статьи с цикла Oracle Forensics на античате: Часть 1: Анализируем Redo-логи by NeMiNeM Часть 2: Нахождение удалённых объектов by VERte][ Часть 3: Поиск доказательств атак на механизм аутентификации by NeMiNeM Часть 4: Live Response by Robin_Hood Часть 5: О нахождении свидетельств кражи данных by Дрэгги |
Перевод весьма качественный. Очень радует тот факт, что статьи иностранных специалистов доступны для наших ребят, не владеющих английским языков на должном уровне.
--Оффтоп, но оценка верна. |
| Время: 20:10 |