В 1999 году шведский взломщик проник на сайт Hotmail (корпорации Microsoft) и создал зеркало, на котором все желающие могли ввести имя любого пользователя этого сайта и прочесть всю его почту, включая архивы.
Русский 19-летний взломщик по имени Максим украл с сайта интернет-магазина номера 300 000 кредитных карт. Затем он обратился к их владельцам и заявил, что если они не заплатят ему $100 000, он опубликует номера кредиток в интернете. Они не поддались на шантаж, и тогда Максим исполнил свою угрозу, что нанесло серьезный ущерб многим невинным жертвам.
Двадцатитрехлетний студент из Калифорнии отправил по электронной почте в агентство новостей фальшивый пресс-релиз, в котором сообщалось об огромных убытках корпорации Emulex и об уходе в отставку ее генерального директора. Спустя несколько часов акции компании упали на 60 %, в результате чего их держатели лишились более $2 млрд. Преступник заработал около четверти миллиона долларов, продав акции без покрытия46 незадолго до своего ложного заявления. Хотя этот случай не является взломом веб-сайта, размещение такого объявления на сайте компании привело бы к аналогичному эффекту.
К сожалению, такие примеры можно перечислять долго. Теперь пора перейти к технической стороне дела. Более подробную информацию о проблемах веб-безопасности всех видов можно найти в работах Ду (Du, 2019), Шнайера (Schneier, 2004), Статтарда и Пинто (Stuttard and Pinto, 2007). Также множество описаний конкретных случаев вы найдете в интернете.
8.12.2. Безопасное именование ресурсов и DNSSEC
Давайте еще раз затронем проблему спуфинга DNS и начнем с самого простого случая. Допустим, Алиса хочет посетить веб-сайт Боба. Она набирает в браузере нужный URL и через несколько секунд видит страницу. Но настоящая ли она? Может, да, а может, нет. Не исключено, что Труди снова взялась за старое. Предположим, она перехватила исходящие пакеты Алисы и изучила их. Отыскав HTTP-запрос GET к сайту Боба, взломщица сама зашла на эту страницу, изменила ее и отправила ни о чем не подозревающей Алисе. Хуже того, Труди может сильно снизить цены в интернет-магазине Боба, тем самым сделав его товары очень привлекательными. Это резко повышает вероятность того, что Алиса вышлет номер своей кредитной карты «Бобу» (с целью приобрести что-нибудь по выгодной цене).
Одним из недостатков традиционной атаки посредника является то, что Труди должна иметь возможность перехватывать исходящий трафик Алисы и подделывать входящий. На практике она должна прослушивать телефонную линию Алисы или Боба (поскольку прослушивать оптоволоконный магистральный кабель — задача непростая). Конечно, перехват телефонных разговоров возможен, но это требует больших усилий, а Труди не только умна, но и ленива.
Кроме того, Алису можно обмануть проще: например, спуфинг DNS, о котором мы говорили в разделе 8.2.3. В двух словах это выглядит так. Злоумышленник сохраняет некорректные данные сопоставления сервиса на промежуточном сервере имен, чтобы сервер направлял пользователей на поддельный IP-адрес. Если пользователь захочет подключиться к сервису, он извлечет этот адрес и в итоге свяжется не с реальным сервером, а со злоумышленником.
Настоящая проблема в том, что служба DNS разрабатывалась в те времена, когда интернет был чисто исследовательской сетью, работавшей в нескольких сотнях университетов, и ни Алиса, ни Боб, ни Труди не были приглашены на этот праздник жизни. Вопрос защиты информации тогда еще не стоял; задача была в том, чтобы интернет вообще функционировал. Но с годами все кардинально изменилось, поэтому в 1994 году IETF создал рабочую группу, которая должна была обеспечить безопасность DNS. Этот проект под названием DNSSEC (DNS Security — защита DNS) действует до сих пор; первая версия представлена в спецификации RFC 2535, а обновление — в RFC 4033–4035. К сожалению, DNSSEC не развернут в полном масштабе, поэтому многие DNS-серверы все еще уязвимы для атак подмены.
Концептуально система DNSSEC очень проста. Она основана на шифровании с открытыми ключами. В каждой зоне DNS (см. главу 7) имеется два ключа — открытый и закрытый. Вся информация, отправляемая DNS-сервером, подписывается с помощью закрытого ключа зоны источника, и принимающая сторона может легко проверить подлинность данных.
DNSSEC предоставляет три основные службы:
1. Подтверждение источника данных.
2. Распространение открытых ключей.
3. Аутентификацию транзакций и запросов.
Первая служба является основной: она проверяет, что пришедшие данные были одобрены владельцем зоны. Вторая служба используется для безопасного хранения и извлечения открытых ключей. Третья позволяет защититься от атак повторного воспроизведения и подмены сервера. Заметим, что конфиденциальность здесь не обеспечивается: такая задача не стоит, поскольку вся информация DNS считается открытой. Изначально предполагалось, что процесс внедрения системы займет несколько лет. Поэтому нужно было организовать взаимодействие между серверами с поддержкой DNSSEC и остальными серверами. Это подразумевает невозможность внесения в протокол каких-либо изменений. Теперь рассмотрим эту систему более детально.
Записи DNS группируются в наборы записей ресурсов (Resource Record Set, RRSET). В таком наборе объединены все записи с одинаковым именем, классом и типом. Например, RRSET может состоять из нескольких записей A, если DNS-имя преобразуется в первичный и вторичный IP-адрес. Наборы расширяются за счет некоторых новых типов записей (они рассмотрены ниже). Каждый RRSET хешируется (например, с помощью SHA-2). Хеш подписывается закрытым ключом зоны (например, с применением RSA). Единицей передаваемой клиентам информации является подписанный RRSET. Получив его, клиент может проверить, действительно ли набор был подписан закрытым ключом зоны отправителя. Если подпись корректна, данные принимаются. Поскольку каждый RRSET содержит собственную подпись, эти наборы можно кэшировать где угодно, даже на не слишком надежных серверах, не опасаясь за их безопасность.
Система DNSSEC вводит несколько новых типов записей. Первая из них — DNSKEY. В ней указывается открытый ключ зоны, пользователя, хоста или другого принципала, криптографический алгоритм генерации подписи, наименование протокола передачи и некоторые другие данные. Открытый ключ хранится в незащищенном виде. Сертификаты X.509 не используются из-за их громоздкости. В поле алгоритма содержится значение 1 для MD5/RSA и другие значения для остальных комбинаций. Поле протокола может указывать на применение IPsec или другого протокола защиты соединений (если он вообще используется).
Второй новый тип записи — RRSIG. В ней содержится подписанный хеш, сформированный согласно алгоритму, который указан в DNSKEY. Подпись охватывает все записи RRSET (в том числе все DNSKEY), за исключением ее самой. Здесь также указано время начала и конца действия подписи, имя ее владельца и некоторая дополнительная информация.
Система DNSSEC устроена так, что для большей надежности закрытый ключ зоны можно хранить вне сети. Один или два раза в день содержимое базы данных зоны вручную переносится (например, на таком безопасном носителе, как старый добрый компакт-диск) на автономный компьютер, где расположен закрытый ключ. Здесь генерируются подписи для всех RRSET, и полученные таким образом записи RRSIG вновь записываются на защищенное устройство и возвращаются на главный сервер зоны. Таким образом, закрытый ключ хранится на безопасном носителе в сейфе и извлекается лишь для того, чтобы подписать ежедневное обновление RRSET на автономном компьютере. По окончании генерации подписей все копии ключа удаляются из памяти, а носитель отправляется в сейф. Эта процедура сводит электронную защиту информации к физической, что гораздо понятнее для пользователей.
Метод предварительного подписания RRSET существенно ускоряет процесс обработки запросов, ведь благодаря ему отпадает необходимость в шифровании на лету. Правда, для хранения всех ключей и подписей в базах данных DNS требуется большой объем дискового пространства. Из-за подписи некоторые записи увеличиваются в размере десятикратно.
Получив подписанный RRSET, клиент применяет открытый ключ зоны отправителя для расшифровки хеша, затем вычисляет хеш самостоятельно и сравнивает два значения. Если они совпадают, данные считаются корректными. Но эта процедура не решает вопрос получения клиентом открытого ключа зоны. Один из возможных подходов сводится к тому, что надежный сервер передает клиенту ключ по защищенному соединению (например, при помощи IPsec).
Однако на практике предполагается, что у клиентов уже есть открытые ключи всех доменов верхнего уровня. Если Алиса пожелает посетить сайт Боба, она запросит у службы DNS набор RRSET для сайта bob.com. Этот набор будет включать IP-адрес и запись DNSKEY с открытым ключом Боба и будет подписан доменом верхнего уровня (com), поэтому Алиса сможет легко проверить его подлинность. На илл. 8.47 показан пример содержимого RRSET.
Теперь, вооружившись заверенной копией открытого ключа Боба, Алиса запрашивает у DNS-сервера Боба IP-адрес сайта www.bob.com. Этот RRSET подписан закрытым ключом Боба, поэтому Алиса может проверить подлинность подписи возвращенного Бобом набора. Если Труди каким-то образом внедрит фальшивый RRSET в один из кэшей, Алиса заметит это, так как запись RRSIG будет неправильной.
Имя домена
Время жизни
Класс
Тип
Значение
bob.com.
86400
IN
A
36.1.2.3
bob.com.
86400
IN
DNSKEY
3682793A7B73F731029CE2737D...
bob.com.
86400
IN
RRSIG
86947503A8B848F5272E53930C...
Илл. 8.47. Пример RRSET для bob.com. Запись DNSKEY содержит открытый ключ Боба. Запись RRSIG содержит хеш записей A и DNSKEY, подписанный сервером домена верхнего уровня com для подтверждения их подлинности
Впрочем, система DNSSEC также предоставляет криптографический механизм для связывания ответов с соответствующими запросами, что исключает возможность проведения атаки подмены данных, о которой мы говорили в начале главы. Эта мера (необязательная) заключается в том, что к ответу добавляется хеш запроса, подписанный закрытым ключом респондента. Поскольку у Труди нет закрытого ключа сервера домена верхнего уровня (com), она не сможет подделать ответ этого сервера на запрос интернет-провайдера Алисы. Конечно, Труди может опередить настоящий ответ, но фальшивка будет отслежена по н