Експлуатація та безпека баз даних Oracle. Частина II, Криптографія, Security & Hack, статті

Частина 1

Зміст



Пошук користувачів


Див статті
“Oracle-користувачі за замовчуванням, їхні паролі і зашифровки ” і
“Вивчення облікових записів за умовчанням в Oracle”


Злом облікового запису програми


Якщо ви змогли увійти в базу даних за допомогою однієї з перерахованих вище облікових записів, Чудово. Що може бути краще облікового запису dba. Якщо ви маєте намір отримати промислові дані, то ідеальними будуть обліковий запис власника схеми або обліковий запис користувача програми. Для визначення інших облікових записів можуть бути корисними такі способи:



Якщо ви отримали доступ як непривілейований користувач, ви зможете отримати список всіх користувачів бази даних, але для отримання хешірованних паролів потрібна обліковий запис dba. Приклад SQL для видачі списку користувачів:

SQL> sho user
USER is “DBSNMP”
SQL> select username
2 from all_users;USERNAME
——————————
SYS
SYSTEM
OUTLN
DBSNMP
MTSSYS
AURORA$ORB$UNAUTHENTICATED
SCOTT
DEMO
ORDSYS
ORDPLUGINS
MDSYS
FINANCE
CTXSYS
TRACESVR
AXA
BXD
PXF 17 rows selected.SQL> spool off

Тут видно, що три користувачі, безсумнівно, не є користувачами Oracle за замовчуванням. Дуже часто паролями таких користувачів будуть звичайні паролі або їх імена. Спробуйте кожного з них, використовуючи ім’я користувача в якості пароля. Якщо у вас є пароль DBA або хтось видав доступ до подання DBA_USERS, спробуйте замість ALL_USERS запросити DBA_USERS, вибираючи також стовпець PASSWORD. У цьому стовпці містяться хешірованние паролі. DBA_USERS – це подання таблиці бази даних USER $, що належить користувачеві SYS.


Зовнішні користувачі


Один клас користувачів Oracle, які можуть полегшити шлях доступу до бази даних, – це зовнішні (external) користувачі. Але для цього потрібно знати їх імена в операційній системі і паролі. Фактично, цих користувачів можна виявити тільки в таблиці USER $ схеми SYS або в поданні DBA_USERS:



SQL> select username,password
2 from dba_users
3 where password=”EXTERNAL”;










   USERNAME PASSWORD
   OPS$PXF EXTERNAL


SQL>


Якщо ви знайшли зовнішнього користувача, вхід в базу даних буде дуже простим:



sputnik:pxf> sqlplus /SQL*Plus: Release 8.1.5.0.0 – Production on Mon Jul 30 20:48:49 2001(c) Copyright 1999 Oracle Corporation. All rights reserved.connected to:
Oracle8i Enterprise Edition Release 8.1.5.0.0 – Production
With the Partitioning and Jave options
PL/SQL Release 8.1.5.0.0 – ProductionSQL>


Якщо ви зможете знайти зовнішнього облікового запису, призначену для dba, то буде навіть краще. В даному випадку префікс OPS $ свідчить, що користувач є зовнішнім (але тільки якщо префікс встановлено у параметрі ініціалізації os_auth_prefix). Цей параметр можна перевірити в svrmgrl, використовуючи команду show parameter os_authent_prefix, або в sqlplus наступним чином:



SQL> col name for a20
SQL> col value for a20
SQL> select name,value
2 from v$parameter
3 where name=”os_authent_prefix”;NAME VALUE
——————– ——————–
os_authent_prefix


Використовуючи значення цього параметра, можна визначити всіх зовнішніх користувачів, запитуючи уявлення ALL_USERS. Якщо параметр os_authent_prefix встановлено, то всі користувачі, імена яких починаються з встановленого префікса, можуть входити в базу даних з операційної системи без вказівки пароля, але у них може бути також визначений пароль для віддаленого входу. Якщо користувач створюється з рядком “Identified externally”, а не з паролем, він може входити в операційну систему без пароля, (проте йому не дозволені віддалені з’єднання).


Все, що потрібно – це мати обліковий запис DBA


Метою виламування бази даних Oracle є отримання облікового запису dba, всіх облікових записів dba. Дійсно, для необмеженого доступу до бази даних Oracle вам не потрібна обліковий запис суперкористувача Oracle SYS. Якщо вам вдасться стати користувачем dba, то можна входити в РСУБД Oracle під ім’ям якого користувача за вашим бажанням, включаючи користувача SYS. На жаль, це може робити тільки dba, так як при цьому використовується недокументированная опція оператора alter user, яка дозволяє змінити пароль користувача на відомий хешірованний пароль. Командний файл su.sql, показаний нижче, можна завантажити з www.pentest-limited.com. Командний файл написаний для Unix, для Windows NT потрібно в рядку, що видаляє тимчасовий файл, вставити DEL.



– Ім’я: su.sql
– Дата: 23-Jul-2001
– Автор: Pete Finnigan
– Опис: з’єднатися як інший користувач,
– Не знаючи його пароль, залишити з’єднання
– Відкритим і відновити установку
– Вихідного пароля користувача.
– Обмеження:
– Потрібен доступ до всіх облікових записів dba.

– Використання: SQL> connect sys / change_on_install
— : SQL> sho user
— : USER is “SYSTEM”
— : SQL> @su system
— : SQL> sho user
— : USER is “SYS”set head off
set feed off
set verify off
set pages 0
set termout off

spool su.lisselect “alter user “//username//”
identified by values “””//password//”””;”
from dba_users
where username=upper(“&&1”);spool off

alter user &&1 identified by temppswd;

connect &&1/temppswd

@su.lis
– Заберіть коментарі для вашої ОС
–host rm -f su.lis
–host del su.lisset head on
set feed on
set verify on
set pages 24
set termout on


Користувач, під ім’ям якого ви з’єдналися, не обов’язково повинен бути dba, але майте на увазі, що під цим ім’ям ви за допомогою даного командного файлу не зможете знову з’єднатися як dba. Якщо хтось хоче вкрасти дані з вашої бази даних, dba може і не знадобитися. Dba може допомогти стати власником схеми, але вам навіть не потрібно бути власником схеми для несанкціонованого перегляду даних, так що бережіться.


Ролі і привілеї Oracle


Oracle має набір вбудованих привілеїв і набір вбудованих ролей. Користувачі РСУБД можуть легко створювати свої власні ролі і керувати наданням прав доступу до них. Можна також призначати ролі ролям, створюючи таким чином ієрархію привілеїв. Всі ролі і привілеї зберігаються в таблицях словника даних, власником яких є SYS. Таблиці, звані DBA_%, можуть переглядатися тільки DBA . Привілеї користувачів зберігаються в аналогічних таблицях USER_%, крім того, є ряд загальних таблиць, доступ до яких дозволено всім користувачам. Всі основні таблиці, що містять інформацію про ролі та привілеї, описані нижче.





















































ПОДАННЯ БАЗИ ДАНИХ

Опис
DBA_USERS Зберігає інформацію про всіх, хто має обліковий запис у базі даних Oracle. Разом з ім’ям і паролем хешірованним користувача зберігається ім’я призначеного йому користувача.
DBA_PROFILE Для кожного профілю зберігає інформацію про ресурси та їх лімітах.
DBA_ROLES Деталізує всі ролі, що містяться в базі даних.
DBA_ROLE_PRIVS Ролі, які були призначені конкретним користувачам та іншим ролям.
DBA_SYS_PRIVS Системні привілеї, які були видані конкретним користувачам або ролям.
DBA_TAB_PRIVS Привілеї Select, Insert і Update, які були видані конкретним користувачам або ролям.
DBA_COL_PRIVS Привілеї Select, Insert і Update, які були видані конкретним користувачам або ролям.
ROLE_ROLE_PRIVS Ролі, призначені іншим ролям.
ROLE_SYS_PRIVS Системні привілеї, видані ролям.
ROLE_TAB_PRIVS Привілеї доступу до таблиць, видані ролям.
ROLE_COL_PRIVS Привілеї доступу до стовпців таблиць, видані ролям.
USER_ROLE_PRIVS Ролі, призначені поточному користувачу.
USER_SYS_PRIVS Системні привілеї, видані активного користувача.
USER_TAB_PRIVS Привілеї доступу до таблиць, видані активного користувача.
USER_COL_PRIVS Привілеї доступу до стовпців таблиць, видані активного користувача.

При доступі як dba для визначення прав доступу будь-якого користувача можна використовувати явний SQL. У показаному нижче прикладі користувач SYSTEM вибирає дані профілю користувача DBSNMP і видані йому привілеї.



spool privs.liscol pr head “Профіль” for a8
col rn head “Ресурс” for a25
col rt head “Тип” for a10
col li head “Значення” for a10
break on pr skipprompt
prompt Деталі профілю
prompt ==============select p.profile pr,
p.resource_name rn,
p.resource_type rt,
p.limit li
from dba_users u,
dba_profiles p
where u.profile=p.profile
and u.username = “DBSNMP”; col gr head “видали” for a8
col tn head “Об’єкт” for a20
col ow head “Власник” for a8
col pr head “Привілей” for a10prompt
prompt Об’єктні привілеї
prompt ====================select t.grantor gr,
t.table_name tn,
t.owner ow,
t.privilege pr
from dba_tab_privs t
where t.grantee = “DBSNMP”; col cn head “Стовпець” for a20prompt
prompt Привілеї стовпців
prompt ===================select c.grantor gr,
c.column_name cn,
c.table_name tn,
c.owner ow,
c.privilege pr
from dba_col_privs c
where c.grantee = “DBSNMP”; col ad head “Адм” for a3
col pr head “Привілей” for a30prompt
prompt Системні привілеї
prompt ====================select s.privilege pr,
s.admin_option ad
from dba_sys_privs s
where s.grantee = “DBSNMP”; col gr head “Видана роль” for a30
col dr head “Def” for a3
col ad head “Адм” for a3 prompt
prompt Привілеї ролей
prompt ================select r.granted_role gr,
r.default_role dr,
r.admin_option ad
from dba_role_privs r
where r.grantee = “DBSNMP”; spool offВ результаті виконання цього SQL отримаємо: Деталі профілю
==============

























































































Профіль Ресурс Тип Значення
 
DEFAULT COMPOSITE_LIMIT KERNEL UNLIMITED
  FAILED_LOGIN_ATTEMPTS PASSWORD UNLIMITED
  SESSIONS_PER_USER KERNEL UNLIMITED
  PASSWORD_LIFE_TIME PASSWORD UNLIMITED
  CPU_PER_SESSION KERNEL UNLIMITED
  PASSWORD_REUSE_TIME PASSWORD UNLIMITED
  CPU_PER_CALL KERNEL UNLIMITED
  PASSWORD_REUSE_MAX PASSWORD UNLIMITED
  LOGICAL_READS_PER_SESSION KERNEL UNLIMITED
  PASSWORD_VERIFY_FUNCTION PASSWORD UNLIMITED
  LOGICAL_READS_PER_CALL KERNEL UNLIMITED
  PASSWORD_LOCK_TIME PASSWORD UNLIMITED
  IDLE_TIME KERNEL UNLIMITE  
  PASSWORD_GRACE_TIME PASSWORD UNLIMITED
  CONNECT_TIME KERNEL UNLIMITED
  PRIVATE_SGAKERNEL UNLIMITE  


16 rows selected.Об’ектние привілеї
==================== Видав Об’ектВладелец Привілей
——– ——————– ——– ———-
SYS DBMS_SYS_SQL SYS EXECUTE Привілеї стовпців
=================== No rows selectedСістемние привілеї
====================
















Привілей Адм
   CREATE ANY TRIGGER NO
   CREATE PUBLIC SYNONYM NO
   UNLIMITED TABLESPACE NO

Привілеї ролей
   ===============




















Видана роль Def Адм
   CONNECT YES NO
   RESOURCE YES NO
   SNMPAGENT YES NO

Зауважимо, що користувачеві DBSNMP під час інсталяції був виданий нестандартний набір привілеїв. Щоб дізнатися, які привілеї були видані користувачу через ролі CONNECT і RESOURCE, потрібно в запитах замінити = “DBSNMP” на in (“CONNECT”, “RESOURCE”) і повторно виконати запити. Для того щоб знайти привілеї користувача, під ім’ям якого ви з’єднані, потрібно в запитах замінити подання DBA_% на подання USER_% і повторно виконати запити.


Ін’єкція SQL


Ін’єкція SQL стає все більш відомою технікою вторгнення в бази даних. В Інтернеті можна знайти багато документів, що описують цю техніку, найбільш цікаві, на наш погляд, такі:


www.wiretrip.net/rfp/p/doc.asp?id=42&iface=6
www.wiretrip.net/rfp/p/doc.asp?id=7&iface=2
www.wiretrip.net/rfp/p/doc.asp?id=60&iface=6


Пошук в Інтернеті не дав нічого, пов’язаного з ін’єкцією SQL безпосередньо в РСУБД Oracle. Можна уявити для Oracle два класи ін’єкцій SQL:


Ін’єкція SQL в стандартні пакети Oracle


Були докладно досліджені вбудовані пакети на предмет ін’єкції в них SQL з метою ескалації привілеїв. Вбудовані пакети можуть бути ін’єктовані для отримання доступу до даних або для зміни користувача даних (спостерігайте за цим).


Дослідження стандартних пакетів можливо навіть в тих випадках, коли вони “згорнуті” (зашифровані) і реалізація прихована, так як в Oracle 7 і більш ранніх версіях тіла пакетів поставлялися з РСУБД у вихідному коді. Також можна читати “згорнуті” пакети і бачити в них деякі частини SQL, що використовується в пакетах. Ми шукали в пакетах SQL-код, частина якого задається параметрами, потім викликали функцію або процедуру, в яку передавали додатковий SQL. Ми намагалися, крім усього іншого, виявити функцію або процедуру, яка змінює пароль користувача SYS. Це вдалося в одному випадку, але тільки при з’єднанні як DBA. При спробах з інших облікових записів виникала помилка ORA-1031. Тож слідкуйте за інформацією, може бути, цю перешкоду буде усунуто.


Виконання довільного SQL в даному випадку, можливо, не має змісту – якщо ми можемо виконувати вбудовані пакети, то ми, природно, маємо привілеї для виконання довільного SQL. Ключовий момент ін’єкції SQL – ескалація привілеїв чи виконання SQL, виконання якого заборонено.


Ін’єкція SQL у додатки Oracle


Використання ін’єкції SQL для вторгнення в бази даних Oracle через існуючі програми повинно бути простішим, незалежно від того, чи мають користувачі власні клієнтські програми, написані за допомогою засобів розробки Oracle або будь-яких інших засобів, або Web-додатки. В даному випадку переслідується мета отримання привілеїв чи доступу до даних і / або їх оновлення, якщо це заборонено.


Єдиний спосіб отримання привілеїв в SQL, наскільки це є, – отримати можливість зміни паролів користувачів, щоб з’єднуватися під їхніми іменами, або видавати себе додаткові привілеї. На рівні Oracle це фактично означає отримання доступу як DBA. У багатьох додатках, які бачили ми, механізми захисту Oracle перебудовані, що, ймовірно, надає можливість отримання в додатках великих привілеїв, ніж у самій РСУБД. Дуже складно говорити про конкретні приклади, оскільки це відверне від загальної теми даного документа. Ми сподіваємося опублікувати на цю тему окрему роботу.


Існує багато інструментів, які можуть використовуватися для ін’єкції SQL. Якщо є можливість отримати доступ до вихідного коду програми, то це буде як не можна краще. Це дозволить визначити поля, що заповнюються користувачами, значення яких формуються як частини операторів SQL. Потрібно знайти таке поле, в якому не перевіряється тип введених даних. Наприклад, числове поле, за допомогою якого можна передати рядок, що містить додатковий оператор SQL, або текстове поле з лапками, не розставленими належним чином.


Якщо вихідний код не доступний, то можна використовувати засоби трасування Oracle і знайти, якщо використовується 12-й рівень трасування, що виконуються під час оператори SQL, а також змінні прив’язки. Нижче описаний командний файл sql.sql (доступний для завантаження в www.pentest-limited.com), Який можна використовувати для вилучення з SGA виконаних операторів SQL, щоб дізнатися, що вони роблять у додатку. Для визначення вмісту бібліотечного кеша використовуйте оператори alter session … Виймайте також SQL з архівних журнальних файлів і змінних прив’язки. Для спостереження за передачею даних від клієнта серверного процесу можна також використовувати аналізатори мережевого трафіку. Для спостереження за відповідними процесами можна використовувати команду Unix truss або команди Linux ltrace і strace.


Важливо розуміти структуру схеми бази даних атакується користувача. Деякі ідеї того, як це робити, викладені в даному документі.


Для використання деяких інструментів потрібен доступ до каталогу трасування або доступ dba, але це не проблема, якщо дослідження виконується в автономній системі, а результати застосовуються в промислових системах


Редагування стандартних пакетів


Стандартні пакети надають можливість вбудовування в базу даних Oracle “черв’яків” або “троянських коней”. Стандартні пакети обговорюються в розділі ” Утиліта PL / SQL wrap”. Вихідний код стандартних пакетів недоступний, але їх все ж можна використовувати як” потайних дверей “в базу даних.


Можна інсталювати і компілювати пакети, такі, як DBMS_UTILITY, в схемах користувачів, таких, як DBSNMP, з додаванням маси фіктивних об’єктів та синонімів. Якщо хтось цим цікавиться, відповідна інформація може бути надана, АЛЕ тут є проблема. Чому пакет інсталюється у схемі DBSNMP? Пакет провоцірующе повідомляє нам в заголовку вихідного тексту, не кажучи вже про пропозицію compile, що SQL, використовуваний в ньому, працює під користувачем SYS. Планувалося інсталювати пакет під користувачем, до якого ми маємо доступ, а потім змінити його так, щоб ми могли отримати привілеї. Але це не працює, і в кінцевому рахунку видається помилка ORA-6509 ICD vector missing.


Наступний план – змінити тіло пакету і повторно інсталювати його в схемі SYS, що ми і зробимо. Внесемо зміни у вихідний код тіла пакета, наприклад: DBMS_SESSION.SET_SQL_TRACE, і повторно інсталюємо його у схемі SYS. У файлі $ ORACLE_HOME / rdbms / admin / prvtutl.plb відредагуємо рядок:



1alter session set sql_trace true:


на



1alter user sys identified by sys:


Повторно виконаємо інсталяцію тіла пакета в схемі SYS і виконаємо функцію під іншим користувачем, таким, як DBSNMP. На жаль, виконання завершиться помилкою ORA-1031. Але якщо виконати функцію як DBA, вона змінить пароль SYS.


Виникає багато питань з цієї потенційної атаці, але це дійсно потенційно слабке місце в системі захисту Oracle. Файл в каталозі $ ORACLE_HOME / rdbms / admin повинен бути доступним для перезапису. Природно, що цей файл виконується, якщо DBA виконує catproc.sql і catalog.sql. Цей файл входить в дані процедури (приклад непоганий; ясно, що DBA використовує функцію DBMS_SESSION.SET_SQL_TRACE для включення трасування). Хакеру потрібно тільки регулярно перевіряти, чи отримав він доступ до бази даних як SYS зі своїм новим паролем. Крім того, хакер може усувати сліди своєї роботи і створювати інші шляхи доступу. Зрозуміло також, що DBA не може не помітити зміни пароля SYS, тому що в багатьох вузлах SYS використовується регулярно.


Злом паролів


Пошук в Інтернеті не виявив конкретних прикладів злому паролів Oracle. Фактична алгоритм шифрування / хешування, який використовується всередині Oracle, не відомий широкій публіці. Зате у неї склалося враження про інформаційну безпеку та алгоритмах, що застосовуються в опції Oracle Advanced Security (але тільки не про метод створення хешірованних паролів, що зберігаються в таблиці SYS.USER $ бази даних).


Що загальновідомо, так це те, що Oracle перед шифруванням виконує необоротне перетворення імені користувача та пароля в рядок фіксованої довжини – 16 символів. Алгоритм досить старий і використовується в багатьох версіях Oracle. Алгоритм видає один і той же хешірованное значення в різних версіях Oracle і на різних платформах.


Набір символів, які можна використовувати в паролі, досить обмежений. Можна використовувати деякі пунктуаційні знаки, але тільки тоді, коли пароль полягає в лапки.


Нічого не варте те, що пароль полягає в лапки, або те, що він не чутливий до регістру, наприклад, паролі “pete” і “PETE” мають один і той же хешірованний пароль в USER $.


PenTest Limited розробила програму злому паролів Oracle. Це інструментальне засіб можна використовувати для атак на словник даних, “лобових” атак користувача SYS, воно може працювати автономно, якщо відомо хеш-значення пароля, або виконувати спроби з’єднання, якщо хеш-значення не відомо.


Недокументовані можливості Oracle


Існує кілька недокументованих можливостей РСУБД Oracle. Деякі хороші приклади:


dbms_sys_sql – Недокументованих пакет, використовуваний самої Oracle в Oracle Replication Options. У ньому є одна цікава функція – parse_as_user, яка дозволяє виконувати в цьому пакеті PL / SQL з правами викликає, а не з правами власника пакета. Функція описана в розділі Функція DBMS_SYS_SQL.PARSE_AS_USER.


oradebug – Відладчик Oracle, що поставляється з РСУБД. Це інструментальне засіб не документовано, так як Oracle насправді не хоче, щоб хто-небудь зопалу використовував його. Трохи докладніше oradebug буде розглянуто в розділі Відладчик oradebug.


current schema – Поточна схема. Недокументована опція оператора alter session для зміни поточної схеми сеансу на схему іншого користувача. (В Oracle9i ця команда документована. – Прим. Пер.) Наприклад:



alter session set current_schema = SYS


Цей оператор змінює поточну схему на схему SYS. Що це нам дає? На жаль, це не дає нам привілеї користувача SYS. Проте дозволяє звертатися до об’єктів, що належать SYS або іншому користувачеві, до яких дозволений доступ, але немає синонімів. Приклад сеансу:



SQL> connect dbsnmp/dbsnmp
SQL> desc user$

ERROR:
ORA-04043: object user$ does not exist

SQL> alter session set current_schema=SYS;
session altered.

SQL>
SQL> desc user$













































































































   Name

Null?

Type
   USER# NOT NULL NUMBER
 
   NAME NOT NULL  
   TYPE# NOT NULL NUMBER
 
   PASSWORD    
   DATATS# NOT NULL NUMBER
 
   TEMPTS# NOT NULL NUMBER
   CTIME NOT NULL DATE
 
   PTIME   DATE
 
   EXPTIME   DATE
 
   LTIME  
DATE
 
   RESOURCE$ NOT NULL NUMBER
 
   AUDIT$   VARCHAR2(38)
 
   DEFROLENOT NULL NUMBER
 
   DEFGRP#   NUMBER
 
   DEFGRP_SEQ#   NUMBER
 
   ASTATUS NOT NULL NUMBER
 
   LCOUNT NOT NULL NUMBER
 
   DEFSCHCLASS   VARCHAR2(30)
   EXT_USERNAME   NVARCHAR2(4000)
   SPARE1   NUMBER
 
   SPARE2   NUMBER
 
   SPARE3   NUMBER
 
   SPARE4   VARCHAR2(1000)
 
   SPARE5   VARCHAR2(1000)
 
   SPARE6   DATE

Недокументовані параметри ініціалізації – Параметри ініціалізації Oracle (параметри файлу INIT.ORA), імена яких починаються зі знака підкреслення, є непідтримуваними параметрами. Повний список цих параметрів можна отримати з x $-таблиць. Ці таблиці будуть розглянуті нижче. Oracle не рекомендує встановлювати ці параметри без спеціального дозволу компанії. Приклад запиту списку всіх прихованих параметрів:



select *
from sys.x$ksppi
where substr(ksppinm,1,1)=”_”;


(Прим. пров.: Цікава динаміка збільшення кількості параметрів ініціалізації в різних версіях Oracle:



































Версія

Документованих

Недокументованих

Усього

6

111

19

130

7

117

68

185

8

193

119

312

8i

203

301

504

9i

251

436

687


)


Деякі з цікавих параметрів – це ті, які дозволяють відкривати базу даних, навіть якщо вона зіпсована. Вони можуть бути використані для відкриття бази даних, створеної з неповних резервних копій, щоб спробувати витягти з неї дані. Такий параметр називається _allow_read_only_corruption (дозволити відновлення тільки для читання зруйнованої бази даних). Є й інші, які також можна використовувати, такі, як _allow_resetlogs_corruption (дозволити відновлення зруйнованої бази даних зі скиданням журналів) та _compatible_no_recovery (відновлення без сумісності). Ці параметри потрібно вставляти в файл ініціалізації і їх не можна використовувати в промисловій базі даних без дозволу Oracle. Ще один корисний параметр – _trace_files_public (загальнодоступні трассіровочние файли), який дозволяє відкрити доступ для читання файлів трасувань.


Інші. Про інші недокументованих можливості вказується на протязі всього цього документа.


Файли з відкритим доступом з читання та файли, що виконуються з правами власників (SUID-і SGID-файли)


У ORACLE_HOME завжди потрібно перевіряти файли з відкритим для всіх користувачів доступом з читання. Особливу увагу слід приділяти файлі трасування, журнальним файлів, реальних файлах даних баз даних, архівним журнальним файлів і будь-яким експортним файлів. Завжди важливо перевіряти каталоги, в які записуються протоколи, / tmp-каталоги і всі каталоги, куди можуть міститися резервні копії та експортні файли. У трасувань файлах можна знаходити (наприклад, командою UNIX grep) оператори ALTER USER, CREATE USER і GRANT CONNECT. В експортних файлах можна виявити імена користувачів і паролі у відкритому тексті, які іноді вставляються для зв’язків баз даних. Крім того, з експортних файлів можна витягати хешірованние паролі.


У деяких виконуваних модулях Oracle існує ряд добре документованих “дірок”, які дозволяють ескаліровать привілеї. Інформацію про це можна знайти в базі даних відслідковування помилок (bugtrack database) за адресою: www.securityfocus.com.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*