взлом Сайт хакера Andrea Purificato, обнаружившего последние баги в Oracle Как правило, информация извлекается одной из двух возможных функций: pg_Fetch_Object и pg_ fetch_array(). Если используется первая функция, то придется явно указывать имя нужного нам столбца в таблице. pg_Fetch_Object возвращает объект, а не массив. В очередной раз проводя аналогию с «мускулом», отмечу, что здесь не нужно знать порядок столбцов, требуется лишь наименование. Получение объекта PostgreSQL с помощью pg_Fetch_Object реализуется простым PHP-сценарием: Ошибка соединения с базой
взлом Пример: «select"username"from"sys».«dba_use rs"where"username"='sys'» 10. Кодирование в ASCII-символ происходит так же, как и в PostgreSQL, — с помощью функции chr(). 11. Для конкатенации используются пайпы («||»). 12. Сайты с бажными скриптами легко ищутся в поисковике: «ORA-00921: unexpected end of SQL command». На официальном сайте можно найти много полезной информации 2. Supplied argument is not a valid PostgreSQL result 3. Warning: pg_exec() [function.pg-exec]: Query failed Перечислять все коды ошибок здесь не имеет смысла. Полезнее обратиться к документации (www.postgresql.org/docs). Немного отойдя от темы, напомню, что поисковик Google является не только удобным средством для обнаружения потенциальной жертвы, но и «историей болезни» многих порталов, поскольку использует кэширование ;). Зачастую уязвимые скрипты, которые заменяются новыми, пропатченными, остаются на сервере. Найти их поможет веб-архив (www.web.archive.org). Заходим, вбиваем адрес нужного нам сайта, находим все доступные скрипты и по очереди выясняем их наличие на сервере. Если таковые обнаруживаются, то проверяем на уязвимости. Здесь мы выполняем простое сканирование. Да — примитивно, да — долго, но это последнее, на что следует идти, если другие решения не найдены. Явление Oracle Про Oracle есть несколько очень хороших статей, ссылки на которые ты найдешь далее, поэтому я упомяну лишь основные моменты: 1. Идентификация СУБД аналогична определению PostgreSQL. xàêåð 05 /101/ 07 / 2. Возможно выполнение таких запросов, как INSERT, DELETE, UPDATE. 3. Использовать limit, как ты это делал в MySQL, в Oracle не получится. Вместо этого используй in (1,2). 4. Подстановка нулей (Null) не сработает для поля типа integer, используй ее только для строкового поля. 5. Одной из самых серьезных ошибок при администрировании Oracle является использование пользователя с максимальными правами (DBSNMP), и естественно, возможный взломщик может внедрять свои запросы, имея максимальные права. 6. Использование разделения выражений символом «;» невозможно. 7. Узнать схему СУБД Oracle можно несколькими способами: «select user from dual», «select name from V$DATABASE», «select SCHEMANAME from v$session» или «select sys.login_user from sys. dual». Зашифрованный пароль (необратимый хэш, генерируемый из пары «юзер && пароль») узнается запросом «select PASSWORD from dba_users или select PASSWORD from user_ users». Версия — запросом «select VERSION from V$INSTANCE», аккаунты пользователей — «select * from sys.dba_users». 8. Используются стандартные комментарии («--»). 9. Вместо пробелов можно использовать кавычки. А как же автоматизация? Пропарсив с десяток страниц поисковика, я нашел всего несколько специализированных утилит для атаки и аудита СУБД Oracle (всевозможные сканеры безопасности не в счет). Это программа NGSSQuirreL от компании Next Generation Security Software, тулза DB Audit от SoftTree и многим уже знакомая русскоязычная утилита Console Oracle Security Scanner от Limpid Byte. Первая и вторая программы подойдут для аудита собственного сервера на уязвимости, но никак не для удаленного анализа системы с целью последующего проникновения. Поэтому выбор очевиден — COSS. С помощью этой утилиты можно узнать версию Oracle и другую полезную информацию (SID, например), выполнять команды, брутить на стандартные аккаунты и т.д. Исходники, к сожалению, не прилагаются. Новости с фронта Во время написания этой статьи в багтраке появилась информация об уязвимостях, найденных в PostgreSQL (7.4) и Oracle (9i/10g). В обоих случаях — sql-injection. В случае с PostgreSQL уязвим модуль contrib/ tsearch2 при объявлении некоторых функций. В Oracle же все намного серьезнее — 4 дыры и 4 эксплойта (http://xakep.ru/post/36944/default.asp). Занавес Я описал лишь основы основ возможностей в Oracle и PostgreSQL. Есть гораздо более сложные структурные атаки, требующие глубоких знаний pgSQL/PL и всех тонкостей вышеназванных СУБД. И если ты имеешь соответствующую подготовку, то я советую тебе прочесть интересный доклад David'a Litchfield'a «Oracle PL/SQL Injection» и статью Chris'a Ahley’я «(More) Advanced SQL Injection», которые можно скачать с моей домашней страницы или взять на диске. z 081
Change language