Для входа в базу данных необходимо выбрать, какое сочетание имени пользователя и его пароля можно использовать. Выбор имени пользователя можно производить с учетом следующих особенностей Oracle:
- в любой БД существуют пользователи SYS (пароль change_on_install) и SYSTEM (пароль manager). Начиная с версии 9 соединение с SYS должно быть только AS SYSDBA. До версии 9 Oracle предлагал заменить эти пароли при инсталляции, а с версии 9 - требует замены, не позволяя использовать пароли по умолчанию при инсталляции;
- в большинстве БД существует пользователь DBSNMP (пароль dbsnmp). Начиная с версии 9 этому пользователю выдана привилегия SELECT CATALOG ROLE, что позволяет получить доступ к содержимому таблиц, владельцем которых является SYS, в частности - к таблице USER$, в которой хранятся пользовательские пароли в виде хешированных значений. В большинстве случаев (особенно, если применяется Oracle Management Server), пользователю DBSNMP предоставляются более значительные привилегии. Простая смена пароля пользователя DBSNMP не позволит применять Oracle Management Server (для этого необходимо изменить параметры настройки в файле snmp_rw.ora - Metalink Note 70174.1 and 168549.1 for details или здесь), поэтому высока вероятность того, что установлен пароль по умолчанию;
- в большинстве БД существуют пользователи, имена и пароли которых известны. Перечень таких пользователей находится здесь, а дополнительные сведения можно посмотреть здесь.
- в большинстве БД существуют пользователи, пароли которых совпадают с их именами.
Таким образом, следующим шагом является попытка установления соединения с использованием ЛЮБОГО username / password. Методы социальной инженерии могут оказаться в этом случае весьма эффективными (если они доступны). Для облегчения рутинной работы по поиску возможных сочетаний имени и пароля пользователя может применяться утилита PassFinger v101, автоматизирующая процесс соединения с выбранной БД как по пользовательской базе username / password , так и по произвольным сочетаниям в ручном или автоматическом режимах. Воспользуемся полученными ранее результатами работы программы TNScaner v201 для поиска доступных сочетаний username / password при помощи утилиты PassFinger v101
Приведенные ниже результаты поиска возможного соединения с БД при помощи утилиты PassFinger v101 показывают, что в рассматриваемом случае получить привилегию DBA не составило никакого труда и не заняло много времени. Пользователю DBSNMP в БД INLS эта роль предоставлена администратором без смены пароля по умолчанию, а администратор БД VIS не сменил установленный по умолчанию пароль для пользователя SYSTEM. Кроме того, эта привилегия дала возможность получить информацию по привилегированным пользователям, пользователям, которые могут соединяться с БД и хешированные значения их паролей. Таким образом, администраторы обеих БД не сделали ничего, чтобы воспрепятствовать несанкционированному доступу любого желающего с получением им максимальных системных привилегий. Полный лог с результатами работы PassFinger v101 можно посмотреть здесь.
Если бы соединение с БД было произведено без привилегии DBA ROLE, то вся эта информация не могла бы быть получена. Единственным результатом был бы перечень пользователей в БД. Предположим, что так и произошло :) Т.е. известно только, что есть возможность соединиться с БД с минимальными привилегиями, используя обнаруженные login/password и известен перечень пользователей БД. Утилита PassFinger v101 позволяет вручную проверить по встроенному перечню паролей по умолчанию любой из возможных вариантов, а также проверить произвольные комбинации паролей - вопрос в терпении нападающего и ответственности администратора БД при назначении\контроле за пользовательскими паролями.
Если администратор БД не установил ограничение на максимальное количество неудачных попыток соединения, то для расширенной проверки паролей всех пользователей воспользуемся утилитой PassChecker v101, которая автоматизирует проверку паролей по умолчанию, а также паролей, совпадающих с именем пользователя . Аналогичный результат можно получить, используя утилиту OraSecurityCheck.
Приведенные ниже результаты работы утилиты PassChecker v101 показывают, что в рассматриваемом случае используются и пароли по умолчанию, и имя пользователя в качестве его пароля. Анализ полного лога программы PassChecker v101 показывает, что в обеих БД имеется весьма значительное количество пользователей, пароли которых не соответствуют требованиям безопасности. Теперь выбор пользователя и подбор пароля для входа в систему с помощью утилиты PassFinger v101 значительно облегчается и получение привилегий DBA становится предрешенным :).
Применение утилит PassFinger v101 и PassChecker v101 упрощают работу по проверке пользовательских паролей, автоматизируя практически все функции по вводу параметров соединения, хранению паролей и тестированию соединения, предоставляя достаточную информацию для поиска пользователя с высокими привилегиями. В рассматриваемом случае этот поиск не представил каких-либо осложнений и информации для получения привилегий DBA более, чем достаточно.
Однако, предположим, что пароли всех ответственных пользователей изменены и получить доступ в качестве привилегированного пользователя не удалось. Утилита PassFinger v101 позволяет провести поиск с целью получения данных о хешированных значениях пользовательских паролей, для чего требуются гораздо меньшие привилегии, чем DBA ROLE. Такой привилегией является, например, SELECT_CATALOG_ROLE, которой обладает, пользователь DBSNMP по умолчанию. Имея информацию от утилиты PassChecker v101 с перечнем пользователей\их_паролей, можно предположить, что довольно высока вероятность обнаружения пользователя с данной привилегией (или другими привилегиями, дающими доступ к чтению из таблицы SYS.USER$). В результате такого поиска утилита PassFinger v101 выдаст перечень пользователей и хешированных значений их паролей, аналогично показанному здесь. Теперь попытаемся использовать эту информацию и получить доступ к самим паролям. Предварительно можно ознакомиться с требованиями к подбору имен пользователей и их паролей и возможностями пакетов NUKER и RANDOM, реализующих механизм подбора пароля по значению хеш-функции.