Научная статья на тему 'Метод защиты файлов в среде СУБД MS Access'

Метод защиты файлов в среде СУБД MS Access Текст научной статьи по специальности «Компьютерные и информационные науки»

CC BY
1553
179
i Надоели баннеры? Вы всегда можете отключить рекламу.
Ключевые слова
ЗАЩИТА ИНФОРМАЦИИ / MDB-ФАЙЛ / ШИФРОВАНИЕ / INFORMATION SECURITY / MDB-FILE / ENCODING

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Пылин Владислав Владимирович

в работе приведен метод защиты файлов базы данных MS Access в формате mdb, основанный на шифровании заголовка mdb-файла, а именно первых 65536 байт файла.

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

the paper presents the method for protecting files of MS Access database, based on encoding the header of mdb-file, namely the first 65536 bytes of the file.

Текст научной работы на тему «Метод защиты файлов в среде СУБД MS Access»

В.В. Пылин

МЕТОД ЗАЩИТЫ ФАЙЛОВ В СРЕДЕ СУБД MS ACCESS

V.V Pylin

METHOD FOR PROTECTING FILES OF MS ACCES DATABASE

Ключевые слова: защита информации, mdb-файл, шифрование.

Keywords: information security, mdb-file, encoding.

Аннотация: в работе приведен метод защиты файлов базы данных MS Access в формате mdb, основанный на шифровании заголовка mdb-файла, а именно первых 65536 байт файла.

Abstract: the paper presents the method for protecting files of MS Access database, based on encoding the header of mdb-file, namely the first 65536 bytes of the file.

Введение

Несмотря на широкое использование системы управления базами данных (СУБД) MS Access, защита указанной СУБД продолжает оставаться на сравнительно низком уровне. Все стандартные способы защиты [1] базы данных (БД) в её среде, и большинство «нестандартных» [6] оказываются так или иначе уязвимыми.

Рассмотрим БД в MS Access в виде файла типа *.mdb и некое клиентское приложение, работающее в среде Windows и осуществляющее чтение данных из БД с целью представления их пользователю. Необходимо осуществить доступ для чтения к БД только с использованием указанного приложения без возможности чтения данных из базы какими-либо другими способами. Предположим, что файл БД полностью доступен злоумышленнику,

а, следовательно, к обработке файла могут быть применены любые программы и методы. Необходимо учесть также и ограничения, связанные с производительностью. Предположим, что к одной и той же БД могут быть подключены до 40-45 пользователей. Кроме того, программа должна эффективно работать как под управлением ОС Windows 98, так и под управлением ОС Windows NT/2000/XP. Это связано с тем, что приложение использует библиотеки операционной системы, версии которых различны, и работа которых может отличаться.

В работах [1,6] показано, что наиболее надёжными методами защиты БД MS Access являются методы, так или иначе осуществляющие криптографические преобразования со структурой или данными базы. Предлагаемый метод основан на использовании прозрачного шифрования [5], предполагающего выполнение операции зашифрования и расшифрования данных автоматически, не требуя какого-либо вмешательства пользователя. При этом подходе работающая с данными программа не замечает, что данные зашифрованы. Другими словами, когда библиотеки ADODB приложения обращаются к файлу БД, они видят самый обычный файл. Но если с этими данными начинает работать любая другая программа, то она видит зашифрованные данные. Между тем, достаточно зашифровать только заголовок БД, чтобы обеспечить невозможность чтения данных из базы.

Для работы с БД в среде СУБД Access используется ADODB. Создаётся подключение к файлу БД (ADODB Connection). Когда заданы все параметры подключения, происходит непосредственно соединение. При этом, происходит чтение первых предварительно зашифрованных 65536 байт файла данных. В этот момент срабатывает защита. Программа перехватывает вызов API функции ReadFile и сама считывает заголовок БД, после чего возвращает дешифрованные данные. Указанный размер «заголовка» получен эмпирическим путём при трассировке программы, обращающейся к БД. О том, что первый 65536 байт mdb-файла занимает служебная информация, свидетельствует также и тот факт, что размер пустой БД Access больше 64 Кб.

При использовании предложенного метода особое внимание заслуживают следующие

аспекты:

- перехват вызова API функции ReadFile;

- выбор алгоритма, применяемого для шифрования (расшифрования) заголовка;

- особенности внедрения метода в приложение.

Перехват вызова API функции ReadFile

Методы перехвата API вызовов в среде Win32 подробно рассмотрены в работе [2]. Был выбран локальный перехват с использованием раздела импорта.

Локальный перехват может быть реализован посредством подмены адреса перехватываемой функции в таблице импорта. В разделе импорта каждого exe- или dll-модуля содержится список всех используемых dll-библиотек. Кроме того, в нем перечислены все импортируемые функции. Вызывая импортируемую функцию, поток получает ее адрес из раздела импорта. Поэтому, чтобы перехватить функцию, надо лишь изменить её адрес в этом разделе. Для того чтобы перехватить произвольную функцию в некотором процессе, необходимо поправить её адрес импорта во всех модулях процесса. Это связано с тем, что процесс может вызывать её не только из exe-модуля, но и из dll-модулей. В нашем случае функция ReadFile вызывается из модуля msjet40.dll - библиотека драйвера MS Jet OLEDB 4.0. Следовательно, необходимо поправить адрес импорта только в этом модуле.

Основным аргументом в пользу использования данного метода является тот факт, что он применим как в ОС Win9X, так и в ОС, семейства Windows NT. Что является одним из необходимых условий при постановке задачи. С его помощью осуществляется перехват функции только для вызывающего приложения. В нашем случае это приложение, работающее с БД. Технические подробности метода, а также исходный код процедур изложен в работе [2].

После того, как произошла замена адреса, библиотека msjet40.dll при чтении будет вызывать новую функцию, назовем её SpecialReadFile. При этом необходимо сначала вызвать оригинальную функцию ReadFile, предварительно запомнив её адрес в модуле kernel32.dll. После этого вызова ReadFile возвратит содержимое буфера с зашифрованными данными, размером 64 Кб. Далее необходимо эти данные расшифровать, записать их по адресу этого же буфера, и возвратить управление вызывающему модулю. Таким образом, происходит расшифрование налету.

Выбор алгоритма для шифрования/расшифрования заголовка

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

Среди множества алгоритмов симметричного шифрования выбор сделан в пользу алгоритма, позволяющего использовать ключи, как можно большей длины. Это связано с ростом производительности программ подбора ключей, средством борьбы с которыми выбран «метод» увеличения длины ключа. Среди популярных алгоритмов симметричного шифрования алгоритм Blowfish обладает высокой стойкостью [3] и позволяет использовать ключи длиной до 448 бит. Именно он и выбран для шифрования заголовка БД. Однако здесь необходимо отметить, что в общем случае выбор алгоритма шифрования при использовании данного подхода к защита mdb-файлов не является критичным и может быть сделан в пользу любого алгоритма шифрования, отвечающего требованиям конкретного пользователя, использующего данный метод защиты.

Особенности внедрения метода защиты mdb-файла в приложение

Необходимо отметить, что основной трудностью при внедрении данного метода в

информационное приложение является отсутствие какого-либо описания структуры mdb-файла СУБД MS Access. Поэтому все смещения при работе с заголовком БД определены экспериментальным путем.

Как отмечено выше, необходимо прочитать первые 64 Кб mdb-файла базы с помощью функции SpecialReadFile и их расшифровать. Однако при перехвате вызова ReadFile неизвестно, на какой позиции стоит курсор в файле, то есть начиная с какого смещения, происходит чтение данных, известен лишь размер читаемых данных. Еще одна сложность заключается в том, что указанное приложение должно работать с 2-мя mdb-файлами: с одним на чтение (его защищаем), а с другим на запись. При этом возникает проблема распознавания, какой файл в данный момент передан на чтение функции SpecialReadFile. Аргументом, указывающим на читаемый файл, является дескриптор файла. Однако только по дескриптору читаемого файла невозможно получить его имя. Для этого применяем метод перехвата API вызова функции CreateFile, с помощью которого происходит открытие файла на чтение. При перехвате этого вызова первоначально вызываем оригинальную функцию, и если был открыт файл с заданным именем, записываем его дескриптор. Далее в функции SpecialReadFile по записанному ранее дескриптору (а вызов CreateFile происходит всегда раньше ReadFile) идентифицируем читаемый файл.

Что касается определения смещения, то есть стартовой позиции чтения буфера, то решить данную проблему удалось следующим образом. В результате исследования работы функции ReadFile установлено, что буфер размером в 64 Кб библиотека считывает только в том случае, если это именно заголовок, то есть первые 64 Кб. Во всех остальных случаях размер буфера составляет либо 4 Кб, либо 512 байт.

Ещё одна трудность заключается в том, что заголовок может читаться несколько раз во время сессии работы с БД. Однако установлено, что если предполагается чтение 64 Кб, то это означает 64 Кб заголовка, и их необходимо расшифровывать. Алгоритм работы SpecialReadFile представлен на рис.1.

Было так же установлено, что библиотека периодически (период порядка 10 секунд) считывает 512 байт, начиная с 3584 байта от начала файла. То есть зашифровывать весь заголовок полностью не удастся, так как при симметричном шифровании используется «режим сцепления блоков». При таком режиме одинаковым блокам открытого текста соответствуют различные блоки шифротекста. Приходится отдельно шифровать блок длиной 3583 байта от начала файла до смещения 3584, и блок, начиная со смещения 4096 до 65536. А блок длиной 512 байт оставляем незашифрованным (Рис. 2).

Представленный подход связан с трудностью определения текущего положения курсора в БД. То есть, неизвестно, какие именно 512 байт необходимо прочитать: те, что являются частью заголовка или это байты, лежащие после заголовка БД. Тем более на практике почти все 512 указанных байт заголовка заполнены нулями.

Пример шифрования заголовка mdb-файла

Рассмотрим пример шифрования заголовка mdb-файла. При этом дамп первых нескольких байт заголовка mdb-файла до шифрования выглядит следующим образом (рис. 3-а).

После шифрования с помощью алгоритма BlowFish [3] на ключе "$CF$7A$8F$8E$F9$CA$70$D4$CF$AE$28$9A$D5$DB$EC$E0$0B$F9$83$0C$90$E3$50 $56$F5$BD$B1$08$40$B0$B8$0F", представляющем собой строку байт в шестнадцатеричной форме длиной 32 байта, этот же самый участок дампа уже имеет другой вид (рис. 3-б).

Полностью же заголовок шифруется в соответствии со структурой шифрования, представленной на рис.2. При таком изменении заголовка mdb-файла после попытки открыть его с помощью MS Access, программа выдаёт сообщение о том, что формат данной базы нераспознаваем. Это так же относится и к программам, выполняющим восстановление файлов БД MS Access, например Access Recovery.

Заключение

Экспериментально доказано, что все методы, ранее используемые для защиты БД в среде MS Access, имеют практические недостатки, приводящие к полному доступу к данным в файле mdb. Это явилось причиной выполненных исследований и поиска нового метода защиты, который на текущий момент представляется наиболее предпочтительным. Предложенный метод на сегодняшний день проходит апробацию. В результате значимых недостатков не обнаружено. По мнению авторов наиболее эффективным решением задачи взлома такого файла БД является взлом симметричного алгоритма шифрования, который имеет доказанную и обоснованную стойкость [3], позволяющую полагаться на его надёжность.

В результате исследования предложенного метода установлено, что производительность работы приложения не снижается, и время, затрачиваемое на расшифровку заголовка, незаметно для пользователя. Стоит обратить внимание на то, что всю схему шифрования можно не раскрывать. То есть полагаться не только на стойкость схемы шифрования за счёт длинного ключа, но и за счёт скрытия самой схемы, по примеру алгоритма ГОСТ 29147-89 [4], где содержание S-блоков не раскрывается, а выбирается для каждой схемы индивидуально.

Рис. 1. Алгоритм работы функции SpecialReadFile

3584 байт 512 61440 байт

байт

Рис. 2. Структура зашифрованного заголовка mdb-файла

00000000 00 01 00 00 53 74 61 6E

00000010 20 44 42 00 01 00 00 00

00000020 E9 A9 67 72 40 3F 00 9C

00000030 79 BA ED 30 BC DF CC 9D

90000040 BC 4E 2D 63 DE 37 B3 DC

00000050 E2 60 BF 0C 56 36 1C EA

90000060 B1 ЭЭ F9 F9 79 5B 5F 2D

00000070 98 FD F0 B5 4A 57 Cl 27

00000080 85 67 C6 IF 27 44 D2 EE

00000090 78 16 0C ED E9 2D 62 D4

000000A0 00 00 00 00 00 00 00 00

000000B0 00 00 00 00 00 00 00 00

000000C0 00 00 00 00 00 00 00 00

000000D0 00 00 00 00 00 00 00 00

64 61 72 64 20 4A 65 74 0 Standard Jet

B5 6E 03 62 60 09 C2 55 DB § Hnfb'°TU

7E 9F 90 FF 85 9A 31 C5 щйдг@? Ь~ЯР ЕЪ1+

63 D9 E4 C3 9F 46 FB 8A у ||30J"lf3cJ<P hflFJK ^N-c |7 їит - T =fuH.

C2 FA 54 C6 66 E6 AD 2E

FI B1 BA 6C 13 43 02 37 i i?V6. ьё> 1NC07

7C 2A 4F E9 7C 99 08 IF ІІІЗ**у[ -і-ОщіІЦЙ*

83 66 5F 95 F8 D0 89 24

CF 65 ED FF 07 C7 46 A1 Eg ’ 0тю-еэ * |1"F6

54 06 00 00 34 2E 30 00 х_¥эщ-ЬиТ* 4.0

00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00

РисЗ-a. Дамп незашифрованного заголовка mdb-файла.

00000000 5A D7 32 97 47 C8 C3 74

00000010 70 82 59 DE 56 D1 E9 17

00000020 72 82 50 2F 46 7B 0C C5

00000030 7A B7 38 44 1A 8C 40 CC

00000040 C6 8A 85 B0 8E F8 FF F8

00000050 4C B8 58 9D 65 21 2D C9

00000060 9C 64 04 B4 35 A1 D6 29

00000070 C7 6D 47 62 89 9B C8 71

00000080 32 72 93 5C 09 10 EE 52

00000090 F0 4C 4A C7 E0 2E 78 9B

000000A0 47 C9 5B EE 2A 16 58 2F

000000B0 EA EA 83 86 16 20 AC 26

000000C0 FA 5E 0A 7D F7 BA DA 78

[ЩШІШЙІІЯ FE IO 42 El 15 HU 69 FE

Рис. 3-б. Дамп зашифрованного заголовка mdb-файла

Библиографический список

1. Вейскас Дж. Эффективная работа: Microsoft Office Access 2003. - СПб.: Питер, 2005. -1168 с.:ил.

2. Рихтер Дж. Windows для профессионалов: создание эффективных Win32 приложений с учетом специфики 64-разрядной версии Windows/Пер, англ - 4-е изд. - СПб; Питер; М.: 2001. - 752 с.; ил.

3. Брюс Шнайер. Прикладная криптография. Протоколы, алгоритмы, исходные тексты на языке Си. - М.: ТРИУМФ, 2002 - 816 с.: ил.

4. ГОСТ 28147-89. Системы обработки информации. Защита криптографическая. Алгоритм криптографического преобразования. Гос. Ком. СССР по стандартам. - М., 1989.

5. Панасенко С.П. Комплексная защита информации. // Информационные технологии. -2001 - № 3 - с. 14-16.

6. Robinson G. Real World Microsoft Access Database Protection and Security. - Berkeley, CA.: Apress, 2003.

i Надоели баннеры? Вы всегда можете отключить рекламу.