Как кто-то может взломать стек шифрования SQL Server 2005?

Question

Это один для всех вас, гуру безопасности.

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

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

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

Что кому-то нужно для взлома зашифрованных полей в базе данных? Мое единственное предположение, что грубая сила не может быть использована из-за силы алгоритма симметричного шифрования, а сам симметричный ключ защищен 4 дополнительными уровнями шифрования:

Windows DPAPI -> Сервер -> База данных -> Сертификат -> Симметричный ключ

что мне кажется довольно тесным.

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

Answer 1

Вот потенциальная атака. Предполагается, что у вас уже есть способ запустить произвольный код в качестве учетной записи службы. Например, вы можете воспользоваться ошибкой удаленного выполнения кода, чтобы получить. Сделав это, довольно просто использовать DPAPI для получения ключа сервера. Сделав это, вы можете получить главный ключ базы данных, хотя вам понадобится какой-нибудь метод грубой силы, чтобы взломать пароль.

Похоже, это будет довольно сложно сделать, в зависимости от надежности пароля, может быть, это невозможно. Является ли служебная учетная запись низкой или высокой привилегированной? Если это учетная запись администратора, вы можете использовать ее (при условии, что она была взломана), чтобы установить кейлоггер для получения пароля.

Answer 2

K. Брайан Келли специализируется на безопасности SQL Server, и он написал несколько хороших статей о том, как обходится шифрование в средах SQL Server, например:

• http://www.sqlservercentral.com/blogs/brian_kelley/archive/2009/02/20/you-must-trust-someone.aspx
• http://www.sqlservercentral.com/blogs/brian_kelley/archive/2009/02/27/a-security-control-inconsistently-applied-is-not-a-control.aspx
• http://www.sqlservercentral.com/blogs/brian_kelley/archive/2009/02/20/you-must-trust-your-dbas.aspx

Если вы действительно в безопасности, я очень рекомендую подписаться на его блог. Он также доступен в Твиттере на http://twitter.com/kbriankelley.

Answer 3

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

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

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

Answer 4

Где-то в памяти хранится этот незашифрованный ключ для возможности шифрования против него, есть ли у злоумышленника возможность получить доступ к уровню SYSTEM, чтобы затем иметь возможность в основном сканировать память или присоединить дополнительный поток к MSSQL .

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