Беззащитность баз данных (Часть 1)

© А. Лукацкий,
заместитель директора по маркетингу
НИП "Информзащита"
Статья была опубликована в журнале "BYTE/Россия"

О базах данных сейчас пишут очень много. И немудрено. Первая половина 2001 г. ознаменовалась официальным выпуском сразу нескольких новых версий систем управления базами данных (СУБД) таких известных производителей, как Oracle, Microsoft и Sybase. Многие авторы подробно описывают, как легко станет жить администраторам, перешедшим на новые версии популярных СУБД. Однако немногие уделяют внимание такому немаловажному аспекту функционирования баз данных, как обеспечение их безопасности. Мало того, даже на сайтах производителей не всегда можно найти сведения о защитных механизмах СУБД. Например, на сайте российского представительства компании Sybase я не нашел ни одного упоминания о защитных свойствах Sybase Adaptive Server - за исключением общих слов о том, что СУБД Sybase защищена от несанкционированного доступа. И это грустно. Недооценка этого аспекта приводит к весьма печальным последствиям. В качестве примеров упомяну кражу 16 тысяч номеров кредитных карт у компании Western Union и кражу конфиденциальной информации об участниках мирового экономического форума в Давосе. Есть и менее известные, но не менее интересные примеры, иллюстрирующие незащищенность баз данных, причем не только в финансовой сфере.

В июне 2000 г. некий Келли сумел проникнуть в базу данных федерального казначейства Австралии. Злоумышленник получил доступ к конфиденциальной информации о 17 000 бизнесменов и сообщил об этом в прямом эфире радиостанции ABC. Что характерно, казначейство отказалось давать какие-либо комментарии по поводу расследования этого дела. Другой пример также показателен, потому что демонстрирует, как используется труд хакеров в политической борьбе. В 2000 г. одна из оппозиционных мексиканских партий наняла хакеров для доступа к засекреченной базе данных правящей революционной партии Мексики (PRI). В результате был получен доступ к данным аудита, со списком ведущих бизнесменов, принимавших участие в сомнительных сделках. В частности, один из кредитов, фигурировавший в этой информации, получило местное отделение правящей партии, а другой - компания, которой владел сын бывшего высокопоставленного члена этой партии. Оказалось также, что три банкира выдали кредиты самим себе. Все это, а также ряд других факторов, привело к проигрышу правящей партии.

И наконец, последний пример. 12 августа 2000 г. неизвестный хакер проник в базу данных, содержащую информацию о 25 тысячах клиентов английской торговой компании Safeway. Его заинтересовали исключительно адреса электронной почты, по которым он сделал рассылку. В разосланном от имени этой компании письме сообщалось о 25%-ном повышении цен, "…а те, кому это не нравится, - говорилось в конце, - могут делать покупки в Tesco или Sainsbury" (т. е. у конкурентов Safeway).

Все это лишний раз говорит о том, что не стоит недооценивать вопросы обеспечения информационной безопасности для баз данных. И не стоит откладывать их "на потом", когда система уже будет введена в строй и в ней начнет циркулировать конфиденциальная информация. Можно даже немного попугать читателя и сказать, что, согласно 274 статье Уголовного кодекса, персонал, отвечающий за функционирование базы данных, может быть привлечен к уголовной ответственности за "нарушение правил эксплуатации ЭВМ… повлекшее уничтожение, блокирование или модификацию охраняемой законом информации" (срок тюремного заключения - до пяти лет).

Как же защитить базы данных от постоянных посягательств различных злоумышленников? Это непростой вопрос, который необходимо решать с каждой из СУБД (Oracle, Microsoft SQL Server, Sybase и т.д.) отдельно. Но прежде чем начать процесс повышения их защищенности, необходимо понять, как же проникают хакеры в базы данных и какие "дыры" при этом задействуются. Именно этой теме и посвящена данная статья. Хочу сразу отметить, что описать все уязвимые места, присущие базам данных, невозможно даже в серии статей. Поэтому я остановлюсь только на наиболее известных и типичных из них, отсылая читателя к более подробным источникам информации. В частности, информация по уязвимостям Oracle доступна по адресу http://otn.oracle.com/deploy/security/alerts.htm, а для Microsoft SQL Server по адресу http://support.microsoft.com. Существует и российский источник информации об уязвимостях СУБД. Это сервер НИП "Информзащита" (http://www.infosec.ru), на котором размещено описание около 300 уязвимостей СУБД Oracle, Microsoft SQL Server и Sybase, обнаруживаемых системой анализа защищенности Database Scanner американской компании Internet Security Systems. Эта система проводит регулярный анализ заданных серверов баз данных, на основе которого выдаются рекомендации по устранению обнаруженных уязвимостей. На сервере НИП "Информзащита" бесплатно можно получить и эту информацию, за которую многие другие компании, занимающиеся консультациями в области информационной безопасности, взимают немалую плату. Итак, перейдем к описанию некоторых слабых мест систем управления базами данных.

Уязвимости сетевого взаимодействия

Большинство современных СУБД построено по технологии клиент-сервер, что подразумевает доступ клиентской части к серверу по каналам связи. В качестве сетевого протокола, по которому осуществляется взаимодействие, как правило, выступает IP (и TCP над ним), поскольку никакой другой из распространенных протоколов не обеспечивает межплатформенного взаимодействия (например, между рабочей станцией Windows 98 и сервером Solaris, да еще через Интернет).

Доступ клиентов к серверу баз данных осуществляется путем обращения к так называемому слушающему сервису, функционирующему на порте с определенным номером (1433 - для Microsoft SQL Server, 1521 - для Oracle и, как правило, 5000 - для Sybase). Несанкционированный доступ к учетной записи, отвечающей за старт и останов слушающего сервиса, приводит к тому, что злоумышленник может остановить данный сервис, тем самым блокировав все попытки подключения клиентов к серверу базы данных.

Рис. 1. Пароль для доступа к "слушающему" сервису.

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

Еще одна уязвимость баз данных, взаимодействующих по протоколу TCP/IP, связана с тем, что информация между клиентом и сервером в абсолютном большинстве случаев передается в незащищенном виде. Установив в сети анализатор протоколов или используя анализатор, встроенный в ОС (как, например, Network Monitor для Windows NT), можно без проблем перехватывать пароли и идентификаторы пользователей, не говоря уже о конфиденциальных данных, хранящихся в БД.

Продолжение статьи

Дополнительную информацию Вы можете получить в компании Interface Ltd.

Обсудить на форуме
Отправить ссылку на страницу по e-mail