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

Побочные каналы

Очень часто противник может по крохам собрать важные сведения, измеряя нечто такое, о чем проектировщики даже не подозревали. Или, по крайней мере, не думали, что «разглашение» может иметь какие–либо последствия для безопасности!

Есть два вида так называемых побочных каналов: связанные с хронометражем и с хранением. По хронометрируемому каналу противник получает информацию о внутреннем устройстве системы, измеряя время выполнения операций. Например, в грехе 11 мы описали простой хронометрируемый канал в процедуре входа в систему TENEX, когда противник мог что–то узнать о пароле, засекая время реакции на ввод неверных паролей. Если первая буква введенного пароля правильна, то система отвечает быстрее, чем в случае неправильной буквы.

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

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

Обычно считается, что поиск в таблице занимает постоянное время, но это не всегда так. Ведь часть таблицы может быть вытеснена из кэша первого уровня (либо из–за того, что таблица слишком велика, либо из–за работы других потоков программы, либо, наконец, из–за того, что в операции участвуют и другие данные).

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

Хронометрируемый канал – это наиболее распространенный вид побочного канала, но есть еще и каналы, связанные с хранением. Такой канал позволяет противнику видеть не предназначенные ему данные и извлекать из них некоторую информацию. Речь может идти, в частности, о выводах на основе свойств коммуникационного канала, которые не являются частью семантики данных и могли бы быть скрыты. Например, просто перехватив зашифрованное сообщение, передаваемое по кабелю, противник уже знает его длину. Обычно длина сообщения не считается важной характеристикой, но при некоторых обстоятельствах может оказаться таковой. А скрыть ее от противника не составило бы большого труда. Достаточно, скажем, передавать зашифрованные данные с постоянной скоростью, чтобы было невозможно выделить границы сообщений. Иногда каналом могут являться метаданные, сопровождающие собственно данные протокола или системы, как, например, атрибуты файловой системы или заголовки протокола, инкапсулирующие зашифрованную полезную нагрузку. Даже если все данные защищены, противник может извлечь из хранящегося в заголовке IP–адреса получателя информацию о том, кто передает (это верно даже для протокола IPSec).

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

Слишком много информации!

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

Вот несколько примеров того, какую информацию не следовало бы сообщать пользователю.

Правильно ли имя пользователя

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

Детальная информация о версии

Раскрытие подробной информации о номере версии позволяет противнику творить свои дела, оставаясь незамеченным. Цель противника – найти уязвимые системы, не оставляя никаких следов своего присутствия. Пытаясь отыскать сетевые службы, которые можно атаковать, противник сначала снимает «цифровой отпечаток» с операционной системы и работающих служб. Можно очень точно идентифицировать многие операционные системы, послав необычный набор пакетов и проверяя полученный ответ (или отсутствие оного). На уровне приложений можно сделать то же самое. Например, Web–сервер Microsoft IIS не настаивает на том, чтобы HTTP–запрос типа GET заканчивался парой символов «возврат каретки /перевод строки», он соглашается на один лишь символ перевода строки. Сервер же Apache в соответствии со стандартом требует наличия обоих символов. Нельзя сказать, что одно приложение правильно, а другое – нет, но различия в поведении помогают определить, с каким из них вы имеете дело. Проведя еще несколько тестов, можно точно выяснить, какой сервер вас обслуживает и, быть может, даже его версию.

Менее надежный метод заключается в том, чтобы послать серверу запрос GET и проанализировать возвращенную в ответе шапку. Вот что мы получим от IIS 6.0: