Robin_Hood
12.11.2007, 21:18
Автор: David Litchfield [davidl@ngssoftware.com]
Дата: 20 апреля 2007
Перевод: Robin_Hood
www.antichat.ru
Любая организация должна иметь четкий план действий на случай непредвиденных ситуаций, атак.. Для тех же, у кого такого плана нет, спонтанным решением может быть выдернуть провод или отсоединить систему от сети. Это понятная реакция, так как дальнейшее вторжение в этом случае невозможно. Учитывая, что атакующий может поставить под угрозу базу данных Oracle с администраторскими привилегиями, можно создать следующий спусковой механизм:
CREATE OR REPLACE TRIGGER VANISH BEFORE SHUTDOWN ON DATABASE
BEGIN
DELETE FROM SYS.AUD$;
END;
/
Когда база данных выключена правильно, сотрется контрольный журнал, что сделает задание исследователя немного сложнее. Конечно, взломщик может сделать больше, чем стереть все аудиторские следы в таком триггере. Оглядываясь на проблемы выше, а также связанные с потерей временной информации, некоторые организации предпочитают обеспечивать анализ системы, пока она подключена к сети. Этот метод называется живой ответ. Живой ответ безопасно хранит всю временную информацию для дальнейшего анализа, другими словами – вся информация, утерянная в результате отключения машины от сети или выключения будет сохранена.
Это дает возможность исследователю собрать информацию в читаемом формате, более удобном чем его сохраненная двоичная копия – к примеру логи. Эта статья затрагивает начальные понятия о живом ответе, но в основном фокусируется на основных аспектах специфики Oracle. Сейчас есть много книг, касающихся живого ответа – лично я могу посоветовать
Real Digital Forensics (Addison-Wesley) by Richard Bejtlich, Keith Jones and Curtis
Rose
Там, где это возможно, исследователь должен брать на себя действия живого ответа, по отношению особы которая близко подобралась к самой системе, по двум причинам.
Во-первых, этот человек может действовать как свидетель, который, в случае суда, поможет усилить впечатление правдивости. Во-вторых, эта особа может помочь исследователю совершить какие либо неправомерные действия, как-то создание нового пользователя с правами администратора.
До более подробного рассмотрения спецификаций Oracle Live Response, я хочу поговорить про
доверие и гарантии этого сервиса. Поскольку он выполняется на уже скомпрометированной системе, можем ли мы ему доверять, точна ли предоставленная информация? Позвольте объяснить на примере. При использовании на Windows сервере, аудитор системы сможет пользоваться всеми средствами на CD. Когда будет вставлен диск и запущена одна из утилит, Windows создаст новый процесс, утилита получит свое адресное пространство, где будет располагать свои dll, т.е. память, которую он использует. Более углубляясь в техническую информацию, командный процессор вызывает CreateProcess(), которая в свою очередь вызывает NTCreateProcess(). Потом ядро создаст объект процесса, выделит память, поместит ntdll.dll в нее. Потом загружается код программы и все используемые DLL. В момент загрузки ntdll.dll в память может быть скомпрометированы доверие и гарантии, при условии, что у нападающего есть полный контроль над системой, в памяти может быть пропатчена ntdll.dll так, что это произведет к полному контролю. Если у нападающего есть полный доступ к системе, он может подделывать результаты ответов.
Из-за этого можно подвергнуть сомнению правильность данных Живого Ответа, но есть другая проблема. Из-за легкой изменчивости информации, как только это пошло, это пошло. Это означает, что Живой Ответ не восстанавливаем, и также мог быть сомнителен в суде. Чтобы предотвратить это, исследователь должен полностью документировать все, что он делают в системе в течение действия Живого Ответа и иметь свидетеля, чтобы подтвердить это.
Так в чем же состоит преимущество Живого ответа, если результаты могут быть подменены? Ну, во первых, не каждый атакующий может полностью скомпрометировать систему, что будет означать подделку результатов; во вторых secondly, большинство не будет скрывать следы атаки, даже если они и захватили систему; в третьих, информация, полученная из Live Response может быть использована немедленно; в четвертых, если Live Response не предоставляет ни какой подозрительной информации, в то время как различные межсетевые экраны указывают на вторжение в систему – анализ наверняка покажет наличие rootkit технологий.
Разобравшись с ответами живого ответа, простите за тавтологию, насколько они надежны и им можно доверять, взглянем на сам Oracle Live Response поближе.
Основные шаги
Во время Живого Ответа, для аудитора системы невозможно не оставить какого либо следа в системе, но он должен постараться сделать этот след как можно меньше заметным. Практически любые действия повлекут за собой запись в системный журнал. Эти изменения неминуемы, но должны быть ожидаемы как допустимые. Что недопустимо для исследователя – создавать новые файлы через редирект данных от Живого Ответа в файл. Это может перезаписать блоки на диске, которые могут содержать удаленную информацию, используемую бы в результате последующего оффлайн-анализа.
Все исходящая информация из Живого Ответа должна быть записана минуя сеть. Есть три способа сделать это: первый – маппингом диска
если система запущена под Windows или Samba, потом используя редирект ввода:
D:\>listdlls.exe > z:\case-0001-listdlls.txt
Использование редиректа может повлечь за собой ошибки, - к примеру, если набрать C вместо Z – это повлечет за собой неприятности. Второй метод направить информацию через сеть, используя netcat или cryptcat. Cryptcat даже предпочтительнее чем netcat из-за шифрования данных. Очевидно,
что любое обращение к потоку “stderr” не будет перенаправлено через сеть – только информация с потока “stdout”:
D:\>type output.c
#include <stdio.h>
int main()
{
fprintf(stdout,"This will be piped/redirected...\n");
fprintf(stderr,"This will not be piped/redirected...\n");
return 0;
}
D:\>output.exe | nc 192.168.1.100 7777
This will not be piped/redirected...
D:\>
Если вы используете пайпы или редирект, важно будет точно записать любые ошибки, направленные на консоль через поток “stderr”. Альтернатива этим двум методам – установить утилиту, работающею прямо через сеть - к примеру, WebJob от KoreLogic. Сервером может быть даже лэптоп, но
исследователь должен быть уверен в наличии свободного пространства для информации в несколько гигабайт.
Специфика Живого Ответа должна быть проведена и основные шаги должны быть усвоены сейчас. Они включают в себя следующую информацию.
Системное время и дата
Исследователь в первую очередь должен выяснить системное время и дату.
Залогиненые пользователи
Список пользователей, находящихся в системе, а так же информация о том, сколько времени они провели, действительно полезна
Список всех пользователей и групп
Включает в себя список всех пользователей, группы и членство в них а так же дата последнего входа пользователей.
Список открытых портов и соединений
До углубления этот вопрос, давайте рассмотрим следующее: Вы отключаете систему от сети или нет. Если так, с какими версиями Windows активное соединение будет сброшено, а информация удалится. Если же не отключать систему от сети, и взломщик до сих пор онлайн, у него больше шансов нанести вред системе. С другой стороны, это позволяет исследователю собрать больше информации о атаке. Ответ на вопрос о отключении или нет должен быть взвешен и тщательно рассмотрен до атаки. Все TCP- и UDP- порты должны быть под контролем, это позволит узнать как нападающий получил контроль над системой. Обращайте внимание на соединения с сервером. В зависимости от того, запущен сервер в shared mode или нет, определит, будет ли клиент коннектится к 1521(подразумевается, что это порт Oracle), или к случайным портам. Другой признак осмотреться – это множество портов, отсылающие SYN пакеты. Это показатель TCP сканирования с хоста исследования.
Список запущенных процессов
Должен быть получен полный список запущенных процессов. Особое внимание стоит уделять шеллам вроде cmd.exe или /bin/sh, не следует спускать глаз с for //bin/sh. Исследователь также должен получить список родительских процессов. В случае, если родительский процесс уже завершен, будет сложнее, но исследование над открытыми хендлами может помочь.
Список DLL
Список DLL или объектов, загружаемых каждым процессом также должен быть получен. Держите ухо востро с старыми именами; Windows смотрит за DLL, загруженными с использованием UNC через сеть.
Список открытых хендлов
Так же важен список, какой процесс какие хендлы открыл. С этим списком можно воспроизвести действия атакующего, идентифицировать родительские процессы.
Дампы памяти
Дампы памяти всех запущенных процессов должны быть собраны для «нормального» просмотра. Ведь атакующий может запустить процесс вроде “notepad”, и используя CreateRemoteThread() загрузить свой код внутрь адресного пространства.
Также обязателен дамп реестра.
Сделайте копии всех логов
Все серверные логии должны быть скопированы для последующего анализа.
Файлы Oracle
Логии, контрольные файлы Oracle могут находиться в различных местах, поэтому узнаем, как их побыстрее найти. Сначала нужно узнать где установлен каждый экземпляр Oracle. В реестре, HKEY_LOCAL_MACHINE\Software\Oracle Registry содержит информацию о каждом. Для каждого экземпляра должен быть выделен загрузочный файл. Его можно найти в “database” (Windows), или “dbs” - *nix. Стандартное имя файла
“spfilesid.ora”, где “sid” – сервисный идентификатор базы данных. Этот файл содержит информацию о местонахождении логов.
audit_file_dest
background_dump_dest
core_dump_dest
db_recovery_file_dest
user_dump_dest
utl_file_dir
control_files
db_create_file_dest
db_create_online_log_dest_n
log_archive_dest
log_archive_dest_n
Исследователь должен брать во внимание, что список, приведенный выше может отличатся от настроек, используемых Oracle, - к примеру если взломщик использует “ALTER SYSTEM” или “ALTER DATABASE”. Позже мы поговорим о получении этой информации, а сейчас рассмотрим данные директории.
Audit_file_dest
Если аудит включен и сконфигурирован на логирование файлов операционной системы, файлы аудита будут расположены в это директории.
Background_dump_dest
Содержит alert.log и маршрутные файлы.
Core_dump_dest
Дампы сервера содержатся в этой папке. Файлы могут обозначать сигнал о переполнении.
Db_recovery_file_dest
Папка flash востановлени, содержит логии отката.
User_dump_dest
Информация о процессах пользователя записана в эту директорию.
Utl_file_dir
Используется для PL/SQL файлов I/O – к примеру, во время использования UTL_FILE.
Control_files
Содержит список контрольных файлов используемых сервром. Они, в свою очередь, содержат информацию о дата файлах.
Db_create_file_dest
Эта директория для дата файлов Oracle. Она опциональна, и может содержать в себе журналы отката и контрольные файлы, если db_create_online_log_dest_n не установлена.
Db_create_online_log_dest_n
Используется, если логи отката не обнаружены.n должна быть заменена цифрой, начинающейся на 1. Опять же таки, опционально.
Log_archive_dest, log_archive_dest_n и log_archive_duplex_dest
Могут использоваться для заархивированных логов отката.
Oracle Data Files
Контрольные файлы содержат расположение дата файлов, но здесь есть потенциальная опасность. Сервер пожжет содержать много терабайтов, иногда даже петабайт или два дата файлов, и невозможно хранить их на сервере. Однако, возможно копировать ключ дата файлов. Это те файлы, в имени которых содержится SYSTEM, SYSAUX, TEMP иUNDO. Все должно быть скопировано на сервер.
Внешние файлы.
Oracle может записывать файлы в файловую систему используя Java и UTL_FILE PL/SQL. Параметр UTL_FILE_DIR указывает, откуда Oracle может читать файлы и куда писать. Файлы могут быть собраны для анализа. Если входящие файлы – астериксы, Oracle может записать их в любое место в файловой системе. Мы также будем коротко обсуждать внешние таблицы.
Прослушивающие логии
Их можно найти в ORACLE_HOME/network/log directory by default.. Если файл не существует, файлы могут находится в ORACLE_HOME/network/admin/listener.ora. Какпредупреждение, местонахождение в этом файле может быть не «живым». К примеру, в Oracle 9 и ранних версиях, если пароль не был установлен, взломщик мог модифицировать местонахождение логов. Команда the «lsnrctl Status» покажет статус входа в лог файл:
C:\oracle\product\10.2.0\db_1\BIN>lsnrctl status
LSNRCTL for 32-bit Windows: Version 10.2.0.2.0 - Production on 06-
APR-2007 01:28:18
Copyright (c) 1991, 2005, Oracle. All rights reserved.
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1) ))
STATUS of the LISTENER
------------------------
Alias LISTENER
Version TNSLSNR for 32-bit Windows: Version
10.2.0.2.0 - Production
Start Date 06-APR-2007 01:27:36
Uptime 0 days 0 hr. 0 min. 41 sec
Trace Level off
Security ON: Local OS Authentication
SNMP OFF
Listener Parameter File
C:\oracle\product\10.2.0\db_1\network\admin\listen er.ora
Listener Log File c:\temp\listener.log
Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(PIPENAME=\\.\ pipe\EXTPROC1ipc)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=APOLLO)( PORT=1521)))
Services Summary...
Service "PLSExtProc" has 1 instance(s).
Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this
service...
The command completed successfully
C:\oracle\product\10.2.0\db_1\BIN>
Мы можем увидеть расположение логов - C:\temp\listener.log. «Статус» будет выглядеть dtplt одинаково:
06-APR-2007 01:30:04 *
(CONNECT_DATA=(CID=(PROGRAM=)(HOST=)(USER=david))( COMMAND=status)(ARG
UMENTS=64)(SERVICE=LISTENER)(VERSION=169869824)) * status * 0
Также, видно записанное время, поэтому перед командой “lsnrctl status” узнайте время.
Запросы к серверу используя SQLPlus
Исследователь должен соединится с сервером с привилегиями SYS, если это возможно. Это позволит получить доступ к информации, необходимой для исследования. После этого, не нужно предпринимать никак действий чтобы поменять базу данных. К примеру, нельзя исполнять все DML операции, такие как , INSERT, UPDATE или DELETE; нельзя создавать обьекты – даже временные глобальные таблицы; нельзя выполнять операции GRANT или REVOKE с привилегиями; нельзя использовать ALTER – особенно чтобы делать дампы лог файлов или дата файлов.
Знайте, что несмотря на эти предупреждения, всего лишь факт соединения с сервером может изменить их: "устанавливающийся" вход может быть создан в
прослушивающем лог файле; может быть вставлена информация в контрольные журналы (AUD$) либо файлы аудита – если соединение не SYS. Когда исполнится SQL, это в корне изменит информацию во многих журналах вроде V$SQL. Вот почему соединение с RDBMS должно быть последним предпринятым исследователем.
Предположим, что исследователь будет использовать sqlplus для соединения с сервером. До соединения, нужно проверить следующие файлы, дабы убедится, что они не содержат никакого SQL кода, выполняющих следующие операции:
$ORACLE_HOME/bin/LOGIN.SQL
$ORACLE_HOME/dbs/LOGIN.SQL
$ORACLE_HOME/SQLPlus/admin/glogin.sql
Еще одно предупреждение – помните проблемы с доверием? Мы не можем обязательно доверять системе, на которой запущен Живой Ответ, это даже более полезно, когда данные идут непосредственно напрямую. Возможно, атакующий еще не получил root привилегии в системе, достаточно тривиально получить DBA во время, когда система запущена. Для того чтобы скрывать свое прибивание в системе, взломщик может модифицировать логии, к примеру, он мог модифицировать DBA_ROLE_PRIVS, скрывая факт администраторских привилегий:
SQL> SELECT GRANTEE FROM DBA_ROLE_PRIVS WHERE GRANTED_ROLE = 'DBA';
GRANTEE
----------------------------
SYS
SYSMAN
SYSTEM
Однако, это будет заметно в запросе к основным таблицам:
SQL> SELECT U.NAME FROM SYS.USER$ U, SYS.SYSAUTH$ A WHERE U.USER# =
A.GRANTEE# AND PRIVILEGE# = (SELECT USER# FROM SYS.USER$ WHERE NAME =
'DBA');
NAME
------------------------------
SYS
HACK101
SYSTEM
SYSMAN
Во время работы sqlplus и до соединения с сервером, все запросы и результаты жолжны быть записано в файл, это может быть достигнуто командой SPOOL, сопровождаемой именем файла. Имя файла должно быть «значащим» - к примеру, должно содержать номер исследования, дату и время:
C:\oracle\product\10.2.0\db_1\BIN>TIME
The current time is: 6:12:22.93
Enter the new time:
C:\oracle\product\10.2.0\db_1\BIN>DATE
The current date is: 27/03/2007
Enter the new date: (dd-mm-yy)
C:\oracle\product\10.2.0\db_1\BIN>SQLPLUS /NOLOG
SQL*Plus: Release 10.2.0.2.0 - Production on Tue Mar 27 06:12:29 2007
Copyright (c) 1982, 2005, Oracle. All Rights Reserved.
SQL> SPOOL C:\IR-CASES\N0017\SQL-CASE-N0017-27-03-2007-06-12-22.TXT
Соединение должно осуществляется с лэптопа через сеть, включать в себя IP исследуемого сервера, номер порта и идентификатор базы данных(SID).
SQL> CONNECT SYS/PASSWORD@192.168.1.100:1521/ORCL AS SYSDBA
Connected.
SQL>
После соединения нужно изменить сессию, задать формат даты, включая минуты, часы, секунды, иначе данные из колонок типа DATE появятся как «ДЕНЬ-МЕСЯЦ-ГОД», к примеру «16-МАР-07».
SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'YYYY-MM-DD HH24:MI:SS';
Узнаем прежде выполненный SQL код
При соединении с сервером, первый запрос, выполненный исследователем должен быть тот, который отобразит последние выполненные запросы. В Oracle 10g запрос будет следующий:
SQL> SELECT LAST_ACTIVE_TIME, PARSING_USER_ID, SQL_TEXT FROM V$SQL
ORDER BY LAST_ACTIVE_TIME ASC;
Это покажет кто и когда исполнял какие команды из списка V$SQL.
Есть ограниченное число записей, около 2500, и это является круглым - то есть старшие записи переписуются с новыми записями. Если исследователь может получить эту информацию как можно быстрее после того, как инцидент замечен тогда есть шанс, что все еще будет подарок свидетельства. На нагруженном сервере, конечно, понижены возможности, но вопрос должен все еще выполняться. Если есть содержание ценности к исследованию тогда пользовательский id и время, в которое был SQL, выполняют, оба доступны. Должно быть отмечено, что эта информация должна также быть доступной в дампах памяти, выполненных ранее.
Дата: 20 апреля 2007
Перевод: Robin_Hood
www.antichat.ru
Любая организация должна иметь четкий план действий на случай непредвиденных ситуаций, атак.. Для тех же, у кого такого плана нет, спонтанным решением может быть выдернуть провод или отсоединить систему от сети. Это понятная реакция, так как дальнейшее вторжение в этом случае невозможно. Учитывая, что атакующий может поставить под угрозу базу данных Oracle с администраторскими привилегиями, можно создать следующий спусковой механизм:
CREATE OR REPLACE TRIGGER VANISH BEFORE SHUTDOWN ON DATABASE
BEGIN
DELETE FROM SYS.AUD$;
END;
/
Когда база данных выключена правильно, сотрется контрольный журнал, что сделает задание исследователя немного сложнее. Конечно, взломщик может сделать больше, чем стереть все аудиторские следы в таком триггере. Оглядываясь на проблемы выше, а также связанные с потерей временной информации, некоторые организации предпочитают обеспечивать анализ системы, пока она подключена к сети. Этот метод называется живой ответ. Живой ответ безопасно хранит всю временную информацию для дальнейшего анализа, другими словами – вся информация, утерянная в результате отключения машины от сети или выключения будет сохранена.
Это дает возможность исследователю собрать информацию в читаемом формате, более удобном чем его сохраненная двоичная копия – к примеру логи. Эта статья затрагивает начальные понятия о живом ответе, но в основном фокусируется на основных аспектах специфики Oracle. Сейчас есть много книг, касающихся живого ответа – лично я могу посоветовать
Real Digital Forensics (Addison-Wesley) by Richard Bejtlich, Keith Jones and Curtis
Rose
Там, где это возможно, исследователь должен брать на себя действия живого ответа, по отношению особы которая близко подобралась к самой системе, по двум причинам.
Во-первых, этот человек может действовать как свидетель, который, в случае суда, поможет усилить впечатление правдивости. Во-вторых, эта особа может помочь исследователю совершить какие либо неправомерные действия, как-то создание нового пользователя с правами администратора.
До более подробного рассмотрения спецификаций Oracle Live Response, я хочу поговорить про
доверие и гарантии этого сервиса. Поскольку он выполняется на уже скомпрометированной системе, можем ли мы ему доверять, точна ли предоставленная информация? Позвольте объяснить на примере. При использовании на Windows сервере, аудитор системы сможет пользоваться всеми средствами на CD. Когда будет вставлен диск и запущена одна из утилит, Windows создаст новый процесс, утилита получит свое адресное пространство, где будет располагать свои dll, т.е. память, которую он использует. Более углубляясь в техническую информацию, командный процессор вызывает CreateProcess(), которая в свою очередь вызывает NTCreateProcess(). Потом ядро создаст объект процесса, выделит память, поместит ntdll.dll в нее. Потом загружается код программы и все используемые DLL. В момент загрузки ntdll.dll в память может быть скомпрометированы доверие и гарантии, при условии, что у нападающего есть полный контроль над системой, в памяти может быть пропатчена ntdll.dll так, что это произведет к полному контролю. Если у нападающего есть полный доступ к системе, он может подделывать результаты ответов.
Из-за этого можно подвергнуть сомнению правильность данных Живого Ответа, но есть другая проблема. Из-за легкой изменчивости информации, как только это пошло, это пошло. Это означает, что Живой Ответ не восстанавливаем, и также мог быть сомнителен в суде. Чтобы предотвратить это, исследователь должен полностью документировать все, что он делают в системе в течение действия Живого Ответа и иметь свидетеля, чтобы подтвердить это.
Так в чем же состоит преимущество Живого ответа, если результаты могут быть подменены? Ну, во первых, не каждый атакующий может полностью скомпрометировать систему, что будет означать подделку результатов; во вторых secondly, большинство не будет скрывать следы атаки, даже если они и захватили систему; в третьих, информация, полученная из Live Response может быть использована немедленно; в четвертых, если Live Response не предоставляет ни какой подозрительной информации, в то время как различные межсетевые экраны указывают на вторжение в систему – анализ наверняка покажет наличие rootkit технологий.
Разобравшись с ответами живого ответа, простите за тавтологию, насколько они надежны и им можно доверять, взглянем на сам Oracle Live Response поближе.
Основные шаги
Во время Живого Ответа, для аудитора системы невозможно не оставить какого либо следа в системе, но он должен постараться сделать этот след как можно меньше заметным. Практически любые действия повлекут за собой запись в системный журнал. Эти изменения неминуемы, но должны быть ожидаемы как допустимые. Что недопустимо для исследователя – создавать новые файлы через редирект данных от Живого Ответа в файл. Это может перезаписать блоки на диске, которые могут содержать удаленную информацию, используемую бы в результате последующего оффлайн-анализа.
Все исходящая информация из Живого Ответа должна быть записана минуя сеть. Есть три способа сделать это: первый – маппингом диска
если система запущена под Windows или Samba, потом используя редирект ввода:
D:\>listdlls.exe > z:\case-0001-listdlls.txt
Использование редиректа может повлечь за собой ошибки, - к примеру, если набрать C вместо Z – это повлечет за собой неприятности. Второй метод направить информацию через сеть, используя netcat или cryptcat. Cryptcat даже предпочтительнее чем netcat из-за шифрования данных. Очевидно,
что любое обращение к потоку “stderr” не будет перенаправлено через сеть – только информация с потока “stdout”:
D:\>type output.c
#include <stdio.h>
int main()
{
fprintf(stdout,"This will be piped/redirected...\n");
fprintf(stderr,"This will not be piped/redirected...\n");
return 0;
}
D:\>output.exe | nc 192.168.1.100 7777
This will not be piped/redirected...
D:\>
Если вы используете пайпы или редирект, важно будет точно записать любые ошибки, направленные на консоль через поток “stderr”. Альтернатива этим двум методам – установить утилиту, работающею прямо через сеть - к примеру, WebJob от KoreLogic. Сервером может быть даже лэптоп, но
исследователь должен быть уверен в наличии свободного пространства для информации в несколько гигабайт.
Специфика Живого Ответа должна быть проведена и основные шаги должны быть усвоены сейчас. Они включают в себя следующую информацию.
Системное время и дата
Исследователь в первую очередь должен выяснить системное время и дату.
Залогиненые пользователи
Список пользователей, находящихся в системе, а так же информация о том, сколько времени они провели, действительно полезна
Список всех пользователей и групп
Включает в себя список всех пользователей, группы и членство в них а так же дата последнего входа пользователей.
Список открытых портов и соединений
До углубления этот вопрос, давайте рассмотрим следующее: Вы отключаете систему от сети или нет. Если так, с какими версиями Windows активное соединение будет сброшено, а информация удалится. Если же не отключать систему от сети, и взломщик до сих пор онлайн, у него больше шансов нанести вред системе. С другой стороны, это позволяет исследователю собрать больше информации о атаке. Ответ на вопрос о отключении или нет должен быть взвешен и тщательно рассмотрен до атаки. Все TCP- и UDP- порты должны быть под контролем, это позволит узнать как нападающий получил контроль над системой. Обращайте внимание на соединения с сервером. В зависимости от того, запущен сервер в shared mode или нет, определит, будет ли клиент коннектится к 1521(подразумевается, что это порт Oracle), или к случайным портам. Другой признак осмотреться – это множество портов, отсылающие SYN пакеты. Это показатель TCP сканирования с хоста исследования.
Список запущенных процессов
Должен быть получен полный список запущенных процессов. Особое внимание стоит уделять шеллам вроде cmd.exe или /bin/sh, не следует спускать глаз с for //bin/sh. Исследователь также должен получить список родительских процессов. В случае, если родительский процесс уже завершен, будет сложнее, но исследование над открытыми хендлами может помочь.
Список DLL
Список DLL или объектов, загружаемых каждым процессом также должен быть получен. Держите ухо востро с старыми именами; Windows смотрит за DLL, загруженными с использованием UNC через сеть.
Список открытых хендлов
Так же важен список, какой процесс какие хендлы открыл. С этим списком можно воспроизвести действия атакующего, идентифицировать родительские процессы.
Дампы памяти
Дампы памяти всех запущенных процессов должны быть собраны для «нормального» просмотра. Ведь атакующий может запустить процесс вроде “notepad”, и используя CreateRemoteThread() загрузить свой код внутрь адресного пространства.
Также обязателен дамп реестра.
Сделайте копии всех логов
Все серверные логии должны быть скопированы для последующего анализа.
Файлы Oracle
Логии, контрольные файлы Oracle могут находиться в различных местах, поэтому узнаем, как их побыстрее найти. Сначала нужно узнать где установлен каждый экземпляр Oracle. В реестре, HKEY_LOCAL_MACHINE\Software\Oracle Registry содержит информацию о каждом. Для каждого экземпляра должен быть выделен загрузочный файл. Его можно найти в “database” (Windows), или “dbs” - *nix. Стандартное имя файла
“spfilesid.ora”, где “sid” – сервисный идентификатор базы данных. Этот файл содержит информацию о местонахождении логов.
audit_file_dest
background_dump_dest
core_dump_dest
db_recovery_file_dest
user_dump_dest
utl_file_dir
control_files
db_create_file_dest
db_create_online_log_dest_n
log_archive_dest
log_archive_dest_n
Исследователь должен брать во внимание, что список, приведенный выше может отличатся от настроек, используемых Oracle, - к примеру если взломщик использует “ALTER SYSTEM” или “ALTER DATABASE”. Позже мы поговорим о получении этой информации, а сейчас рассмотрим данные директории.
Audit_file_dest
Если аудит включен и сконфигурирован на логирование файлов операционной системы, файлы аудита будут расположены в это директории.
Background_dump_dest
Содержит alert.log и маршрутные файлы.
Core_dump_dest
Дампы сервера содержатся в этой папке. Файлы могут обозначать сигнал о переполнении.
Db_recovery_file_dest
Папка flash востановлени, содержит логии отката.
User_dump_dest
Информация о процессах пользователя записана в эту директорию.
Utl_file_dir
Используется для PL/SQL файлов I/O – к примеру, во время использования UTL_FILE.
Control_files
Содержит список контрольных файлов используемых сервром. Они, в свою очередь, содержат информацию о дата файлах.
Db_create_file_dest
Эта директория для дата файлов Oracle. Она опциональна, и может содержать в себе журналы отката и контрольные файлы, если db_create_online_log_dest_n не установлена.
Db_create_online_log_dest_n
Используется, если логи отката не обнаружены.n должна быть заменена цифрой, начинающейся на 1. Опять же таки, опционально.
Log_archive_dest, log_archive_dest_n и log_archive_duplex_dest
Могут использоваться для заархивированных логов отката.
Oracle Data Files
Контрольные файлы содержат расположение дата файлов, но здесь есть потенциальная опасность. Сервер пожжет содержать много терабайтов, иногда даже петабайт или два дата файлов, и невозможно хранить их на сервере. Однако, возможно копировать ключ дата файлов. Это те файлы, в имени которых содержится SYSTEM, SYSAUX, TEMP иUNDO. Все должно быть скопировано на сервер.
Внешние файлы.
Oracle может записывать файлы в файловую систему используя Java и UTL_FILE PL/SQL. Параметр UTL_FILE_DIR указывает, откуда Oracle может читать файлы и куда писать. Файлы могут быть собраны для анализа. Если входящие файлы – астериксы, Oracle может записать их в любое место в файловой системе. Мы также будем коротко обсуждать внешние таблицы.
Прослушивающие логии
Их можно найти в ORACLE_HOME/network/log directory by default.. Если файл не существует, файлы могут находится в ORACLE_HOME/network/admin/listener.ora. Какпредупреждение, местонахождение в этом файле может быть не «живым». К примеру, в Oracle 9 и ранних версиях, если пароль не был установлен, взломщик мог модифицировать местонахождение логов. Команда the «lsnrctl Status» покажет статус входа в лог файл:
C:\oracle\product\10.2.0\db_1\BIN>lsnrctl status
LSNRCTL for 32-bit Windows: Version 10.2.0.2.0 - Production on 06-
APR-2007 01:28:18
Copyright (c) 1991, 2005, Oracle. All rights reserved.
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1) ))
STATUS of the LISTENER
------------------------
Alias LISTENER
Version TNSLSNR for 32-bit Windows: Version
10.2.0.2.0 - Production
Start Date 06-APR-2007 01:27:36
Uptime 0 days 0 hr. 0 min. 41 sec
Trace Level off
Security ON: Local OS Authentication
SNMP OFF
Listener Parameter File
C:\oracle\product\10.2.0\db_1\network\admin\listen er.ora
Listener Log File c:\temp\listener.log
Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(PIPENAME=\\.\ pipe\EXTPROC1ipc)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=APOLLO)( PORT=1521)))
Services Summary...
Service "PLSExtProc" has 1 instance(s).
Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this
service...
The command completed successfully
C:\oracle\product\10.2.0\db_1\BIN>
Мы можем увидеть расположение логов - C:\temp\listener.log. «Статус» будет выглядеть dtplt одинаково:
06-APR-2007 01:30:04 *
(CONNECT_DATA=(CID=(PROGRAM=)(HOST=)(USER=david))( COMMAND=status)(ARG
UMENTS=64)(SERVICE=LISTENER)(VERSION=169869824)) * status * 0
Также, видно записанное время, поэтому перед командой “lsnrctl status” узнайте время.
Запросы к серверу используя SQLPlus
Исследователь должен соединится с сервером с привилегиями SYS, если это возможно. Это позволит получить доступ к информации, необходимой для исследования. После этого, не нужно предпринимать никак действий чтобы поменять базу данных. К примеру, нельзя исполнять все DML операции, такие как , INSERT, UPDATE или DELETE; нельзя создавать обьекты – даже временные глобальные таблицы; нельзя выполнять операции GRANT или REVOKE с привилегиями; нельзя использовать ALTER – особенно чтобы делать дампы лог файлов или дата файлов.
Знайте, что несмотря на эти предупреждения, всего лишь факт соединения с сервером может изменить их: "устанавливающийся" вход может быть создан в
прослушивающем лог файле; может быть вставлена информация в контрольные журналы (AUD$) либо файлы аудита – если соединение не SYS. Когда исполнится SQL, это в корне изменит информацию во многих журналах вроде V$SQL. Вот почему соединение с RDBMS должно быть последним предпринятым исследователем.
Предположим, что исследователь будет использовать sqlplus для соединения с сервером. До соединения, нужно проверить следующие файлы, дабы убедится, что они не содержат никакого SQL кода, выполняющих следующие операции:
$ORACLE_HOME/bin/LOGIN.SQL
$ORACLE_HOME/dbs/LOGIN.SQL
$ORACLE_HOME/SQLPlus/admin/glogin.sql
Еще одно предупреждение – помните проблемы с доверием? Мы не можем обязательно доверять системе, на которой запущен Живой Ответ, это даже более полезно, когда данные идут непосредственно напрямую. Возможно, атакующий еще не получил root привилегии в системе, достаточно тривиально получить DBA во время, когда система запущена. Для того чтобы скрывать свое прибивание в системе, взломщик может модифицировать логии, к примеру, он мог модифицировать DBA_ROLE_PRIVS, скрывая факт администраторских привилегий:
SQL> SELECT GRANTEE FROM DBA_ROLE_PRIVS WHERE GRANTED_ROLE = 'DBA';
GRANTEE
----------------------------
SYS
SYSMAN
SYSTEM
Однако, это будет заметно в запросе к основным таблицам:
SQL> SELECT U.NAME FROM SYS.USER$ U, SYS.SYSAUTH$ A WHERE U.USER# =
A.GRANTEE# AND PRIVILEGE# = (SELECT USER# FROM SYS.USER$ WHERE NAME =
'DBA');
NAME
------------------------------
SYS
HACK101
SYSTEM
SYSMAN
Во время работы sqlplus и до соединения с сервером, все запросы и результаты жолжны быть записано в файл, это может быть достигнуто командой SPOOL, сопровождаемой именем файла. Имя файла должно быть «значащим» - к примеру, должно содержать номер исследования, дату и время:
C:\oracle\product\10.2.0\db_1\BIN>TIME
The current time is: 6:12:22.93
Enter the new time:
C:\oracle\product\10.2.0\db_1\BIN>DATE
The current date is: 27/03/2007
Enter the new date: (dd-mm-yy)
C:\oracle\product\10.2.0\db_1\BIN>SQLPLUS /NOLOG
SQL*Plus: Release 10.2.0.2.0 - Production on Tue Mar 27 06:12:29 2007
Copyright (c) 1982, 2005, Oracle. All Rights Reserved.
SQL> SPOOL C:\IR-CASES\N0017\SQL-CASE-N0017-27-03-2007-06-12-22.TXT
Соединение должно осуществляется с лэптопа через сеть, включать в себя IP исследуемого сервера, номер порта и идентификатор базы данных(SID).
SQL> CONNECT SYS/PASSWORD@192.168.1.100:1521/ORCL AS SYSDBA
Connected.
SQL>
После соединения нужно изменить сессию, задать формат даты, включая минуты, часы, секунды, иначе данные из колонок типа DATE появятся как «ДЕНЬ-МЕСЯЦ-ГОД», к примеру «16-МАР-07».
SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'YYYY-MM-DD HH24:MI:SS';
Узнаем прежде выполненный SQL код
При соединении с сервером, первый запрос, выполненный исследователем должен быть тот, который отобразит последние выполненные запросы. В Oracle 10g запрос будет следующий:
SQL> SELECT LAST_ACTIVE_TIME, PARSING_USER_ID, SQL_TEXT FROM V$SQL
ORDER BY LAST_ACTIVE_TIME ASC;
Это покажет кто и когда исполнял какие команды из списка V$SQL.
Есть ограниченное число записей, около 2500, и это является круглым - то есть старшие записи переписуются с новыми записями. Если исследователь может получить эту информацию как можно быстрее после того, как инцидент замечен тогда есть шанс, что все еще будет подарок свидетельства. На нагруженном сервере, конечно, понижены возможности, но вопрос должен все еще выполняться. Если есть содержание ценности к исследованию тогда пользовательский id и время, в которое был SQL, выполняют, оба доступны. Должно быть отмечено, что эта информация должна также быть доступной в дампах памяти, выполненных ранее.