Атаки, специфические для баз данных

Противостояние «брони» и «снаряда» характерно для всех на­правлений человеческой деятельности и является формой проявления диалектического закона единства и борьбы противоположностей. Особенность противостояния в сфере баз данных состоит в том, что СУБД—это программный комплекс, и, следовательно, для деструк­тивного воздействия на систему можно задействовать весь богатый арсенал разработок, используемых для взлома операционных систем. Исторически операционные системы, рассматриваемые как среды обработки данных, появились раньше СУБД и объективно более широко распространены. Поэтому именно операционные системы явились основным полигоном разработки и испытания технологий деструктивного воздействия на обрабатываемую информацию. Многие идеи и методы нарушения информационной безопасности баз данных были «портированы» из области операционных систем. Многие методы обеспечения конфиденциальности, целостности и доступности, применяемые в сфере защиты баз данных, имеют про­тотипы в технологиях, развиваемых для операционных систем.

Но нельзя не заметить, что проблеме обеспечения инфор­мационной безопасности баз данных присуща определенная специфика. Источником дополнительных, специфических для баз данных, угроз являются:

— стандарт и реализация языка SQL — основного средства описания и обработки данных;

— обязательный интерфейс между СУБД и операционной системой, под управлением которой ведется обработка данных;

— протоколы сетевого взаимодействия на прикладном уровне, которые обеспечиваются средствами СУБД.

3.1. Подбор и манипуляция с паролями как метод реализации несанкционированных прав

Любая система обработки данных, допускающая многополь­зовательский режим работы, предусматривает идентификацию и аутентификацию пользователей и процессов как обязательное предусловие предоставления доступа к ресурсам системы. Широко распространенной технологией аутентификации является использование паролей. Естественно ожидать, что технология подбора паролей также находится на достаточно высоком уровне развития. Можно выделить следующие методы подбора паролей пользователей.

1. Тотальный перебор. В этом случае злоумышленник последовательно опробует все возможные варианты пароля. Для паролей длиннее шести символов во многих случаях данный метод может быть признан неэффективным.

2. Тотальный перебор, оптимизированный по статистике встречаемости символов. Разные символы встречаются в паролях пользователей с разной вероятностью. Например, вероятность того, что в пароле пользователя встретится буква «а», гораздо выше вероятности того, что в пароле присутствует символ «^». Согласно различным исследованиям, статистика встречаемости символов в алфавите паролей близка к статистике встречаемости символов в естественном языке.

При практическом применении данного метода злоумышленник вначале опробует пароли, состоящие из наиболее часто встречающихся символов, за счет чего время перебора существенно сокращается. Иногда при подборе паролей используется не только статистика встречаемости символов, но и статистика встречаемости диграмм и триграмм — комбинаций двух и трех последовательных символов соответственно.

Для подбора паролей по данному методу в разное время было написано множество программ, в основном ориентированных на излом операционных систем.

Можно выделить две базовые технологии:

— явное опробование последовательно генерируемых паролей подачей их на вход подсистемы аутентификации;

— расчет значения хэш-функции и ее последующего сравнения с известным образом пароля.

Особенность второго варианта состоит в том, что при известном образе пароля задача эффективно распараллеливается и может решаться без активного взаимодействия с атакуемой системой.

3. Тотальный перебор, оптимизированный с помощью словарей. В большинстве случаев пароли пользователей представляют собой слова английского или русского языка. Поскольку пользователю гораздо легче запомнить осмысленное слово, чем бессмысленную последовательность символов, пользователи предпочитают применять в качестве паролей осмысленные слова. При этом количество возможных вариантов пароля резко сокращается. Словарь С. И. Ожегова содержит около 60000 слов, объем словаря среднестатистического пользователя заметно меньше.

При использовании данного метода подбора паролей злоумышленник вначале опробует в качестве паролей все слова из словаря, содержащего наиболее вероятные пароли. В сети Интернет представлено множество подобных словарей, адаптированных для различных стран и групп пользователей. Если подбираемый пароль отсутствует в словаре, злоумышленник, как правило, может опробовать всевозможные комбинации слов из словаря, слова из словаря с добавленными к началу или к концу одной или несколькими буквами, цифрами и знаками препинания и т. д. «Хитрости» с написанием слов в обратном порядке в иной раскладке клавиатуры также не являются чем-то новым.

Обычно данный метод используется в комбинации с предыдущим.

4. Подбор пароля с использованием знаний о пользователе. Человек склонен использовать пароли, которые легко запоминаются. Многие пользователи, чтобы не забыть пароль, выбирают в качестве пароля свое имя, фамилию, дату рождения, имена детей, любимых (в том числе принятые в узком кругу), номера телефонов и автомобилей и т. д. Хорошо известно, что некоторая категория мужчин склонна использовать в качестве (не отображаемого на дисплей) пароля ненормативную лексику, а определенная категория женщин часто использует уменьшительно-ласкательные имена домашних животных. В этом случае, если злоумышленник хорошо изучил пользователя, ему, как правило, достаточно провести меньше сотни опробований.

Базовые процедуры аутентификации на основе паролей в большинстве современных СУБД построены на сравнении вычисляемой значения хэш-функции от вводимого пароля с хранимым образом пароля, приписанного пользователю. Для вычисления образов паролей используются стандартные хэш-функции, поэтому их криптографические свойства не вызывают сомнения. Количество опробований (неуспешных попыток ввода) пароля устанавливается в профиле пользователя.

Наиболее слабым местом базовой процедуры аутентификации, видимо, является возможность доступа к образу пароля приви­легированного пользователя. Если не используется процедура аутентификации средствами операционной системы, то образ пароля хранится в справочнике данных. В этом случае привилегированный пользователь может не только считать образ для организации подбора пароля, но и незаметно для пользователя временно подменить пароль и выполнить некоторые действия от чужого имени.

3.2. Нецелевое расходование вычислительных ресурсов сервера

Выполнение запросов и иные обращения к серверу баз данных связаны с расходованием его ресурсов, в первую очередь времени процессора, оперативной и внешней памяти. Это очевидное утверждение имеет одно неочевидное следствие. Если пользователю предоставлена возможность создавать процедуры и их выполнять, то может возникнуть проблема нарушения доступности в связи с нецелевым расходованием ресурсов.

Ясно, что запуск процедуры приведет к «замиранию всего живого» в системе. Эффект от подобной атаки может быть уменьшен назначением пользователю профиля, ограничивающего максимальное выделяемое время центрального процессора.

Напомним, что система контроля ограничений на ресурсы должна быть приведена в активное состояние.

Бороться с процедурами, расходующими ресурсы системы нецелевым образом, да и с иными деструктивными процедурами офицер безопасности может и принудительным завершением процессов-вредителей.

3.3. Использование триггеров для выполнения незапланированных функций

Специфические для баз данных объекты —триггеры — широко используются для обеспечения конфиденциальности и целостности данных. Автоматическое срабатывание триггера при выполнении операций языка манипулирования данными INSERT, DELETE, UPDATE создает возможности для дополнительного аудита и программируемого контроля выполняемых операций.

3.4. Использование SQL-инъекции для нештатного использования процедур и функций

Использование процедур и функций для параметрических запросов является широко распространенной практикой создания элементов информационных систем. Во многих случаях запрос к базе данных не зависит от параметров. Такой запрос называется статическим.

При использовании статического запроса программист создает PL/SQL программу, включая в код необходимые SQL-предложения. В зависимости от содержащихся в базе данных формируется некоторый результат, например отчет о расходах или поступлениях товаров на склад на плановый период. В этом случае в тексте программы все SQL-предложения, которые необходимы в процессе ее работы, явно описываются, компилируются и могут храниться в вызываемых процедурах или функциях.

Но возможны и иные варианты. Например, значение параметра запроса (фамилия, адрес) зависит от ситуации. Для решения таких задач необходим механизм динамически формируемых SQL-предложений. Самое простое решение — предоставить пользователю оболочку для формирования запросов на языке SQL. Для реализации такого варианта пользователи должны владеть языком SQL. Это дорогое решение, к тому же создающее серьезные проблемы с безопасностью.

Чаще используется другой вариант: создаются программы на PL/SQL или ином языке с параметрами, которые отражают специфику запроса.

В комплект поставки сервера Oracle входит стандартный пакет DBMS_SQL, обеспечивающий выполнение динамически формируемых SQL-предложений в программах на PL/SQL. Динамические SQL-предложения конструируются непосредственно во время выполнения программы в виде символьной строки, а затем передаются соответствующим программам пакета DBMS_SQL для разбора и исполнения.

Ответственность за возможное нарушение объектных за­висимостей и прав доступа, которые Oracle в данном случае во время компиляции не может проверить, теперь ложится на программиста.

Для динамически сформированных операторов SQL, которые возвращают данные (т. е. для операторов SELECT), используется следующая последовательность обработки: открытие курсора, разбор запроса, связывание переменных, определение столбцов, выполнение запроса, выборка строк, получение значений столбцов, закрытие курсора.

Конечно, более изящно решение выполнения параметрического запроса с использованием динамического SQL. Но и в этом случае, несмотря на кажущуюся жесткость управления действиями пользователя, возможно деструктивное действие, известное как SQL-инъекция.