Безопасность и современные тренды

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

Кроме того, если раньше из-за ошибки программирования мог разбиться о поверхность Марса спутник или взорваться ракета «Ариан-5», то сейчас ошибки такого рода начинают затрагивать миллионы «гражданских». Как защищаются от «подглядывания» и ошибок в современных технологиях; как берегут персональные и не только данные; как противостоят не только софтверным, но и аппаратным атакам? Рассмотрим эти вопросы подробнее на нескольких примерах.

Монополизация DNS: браузеры и лидеры рынка атакуют

В середине октября 2018 года в Амстердаме прошел очередной семинар сообщества DNS-OARC3. Как обычно, темы семинара были актуальны и интересны, но одну из тем, тему инкапсуляции протоколов DNS в TLS (DNS over TLS – DoT) и HTTPS (DNS over HTTPS – DoH), хотелось бы выделить отдельно. Но прежде обратимся к классическому сервису DNS.

DNS – это сервис сопоставления легко запоминаемого имени и трудно запоминаемого адреса. В этом суть. С переходом на IPv6 роль трансляции имени в адрес и наоборот стала еще более важной. Внешне, скажем, в вебе, это выглядит так: пользователь в адресной строке вводит доменное имя и за доли секунды получает необходимый контент. Вся «кухня» отображения имени в адрес от пользователя скрыта. А процедура эта непростая, и как в любой непростой технологии, в ней возможны ошибки и преднамеренное искажение соответствия. Эти «тонкости» могут привести к тому, что конечный пользователь может оказаться в «параллельной реальности», т.е. получить совсем не тот контент, который он предполагал получить. Таким образом, решение проблемы состоит в том, чтобы удостоверить источник DNS-информации. С этой целью в систему DNS было имплементировано расширение,которое известно под названием «DNSSEC».

Казалось бы, все в порядке – сторонние злоумышленники не смогут обмануть доверчивых пользователей. Проблема возникла совершенно с противоположной стороны. В эпоху тотальной защиты персональных данных (чего стоит только директива GDRP) встал вопрос защиты самого DNS-трафика от посторонних глаз. В первую очередь речь идет о защите DNS-запросов на пути от конечного пользователя к резолверу, который выполняет поиск IP-адреса в системе DNS. Обычно это тот самый DNS-сервер, адрес которого присылается по протоколу DHCP при подключении компьютера к сети. Но в последнее время стало модно отказываться от DNS-резолвинга своего собственного провайдера и прописывать в качестве резолвера DNS-серверы Yandex (77.88.8.8), Google (8.8.8.8), CloudFlare (1.1.1.1). Все они предлагают дополнительные возможности по управлению резолвингом, но при этом запросы пользователя «уходят в плавание» по Интернету. Для защиты от «подсматривания» DNS-провайдеры предлагают различные технологии шифрования. Yandex, например, DNSCRYPT (Cisco – OpenDNS), в то время, как Google и CloudFlare стараются опереться на предлагаемые в RFCболее общие стандарты DoT и DoH. В обоих случаях при обработке запросов используется транспорт TCP. Об UDP речи не идет вообще. В случае DoT используется порт 853, а в случае DoH – стандартный 443 порт.

Различия подходов прекрасно описаны Джефом Хюстоном в блоге APNIС. В первом случае DNS просто «заворачивается» в защищенное TCP-соединение. Второй случай гораздо интереснее, так как сам запрос и ответ могут быть представлены в виде традиционных сообщений HTTP.

Ниже приведен пример резолвинга с использованием протокола DoH и JSON-форматом запросов и ответов.

curl -s-H ‘accept: application/dns+json”https://dns.google.com/resolve?name=kremlin.ru&type=A’ | jq

> GET/resolve?name=kremlin.ru&type=A HTTP/2

>Host: dns.google.com

>User-Agent: curl/7.54.0

>accept: application/dns+json

*Connection state changed (MAX_CONCURRENT_STREAMS updated)!

<HTTP/2 200

<strict-transport-security: max-age=31536000; includeSubDomains; preload

<date: Mon, 15 Oct 2018 12:11:26 GMT

<expires: Mon, 15 Oct 2018 12:11:26 GMT

<cache-control: private, max-age=59

<content-type: application/x-javascript; charset=UTF-8

<server: HTTP server (unknown)

<x-xss-protection: 1; mode=block

<x-frame-options: SAMEORIGIN

<alt-svc: quic=”:443″; ma=2592000; v=”44,43,39,35″

<accept-ranges: none

<vary: Accept-Encoding

{ [379bytes data]

*Connection #0 to host dns.google.com left intact

{

“Status”:0,

“TC”:false,

“RD”:true,

“RA”:true,

“AD”:false,

“CD”:false,

“Question”:[

{

“name”:“kremlin.ru.”,

“type”:1

}

“Answer”:[

{

“name”:“kremlin.ru.”,

“type”:1,

“TTL”:59,

“data”:“95.173.136.70”

{

“name”:“kremlin.ru.”,

“type”:1,

“TTL”:59,

“data”:“95.173.136.72”

{

      “name”:“kremlin.ru.”,

      “type”:1,

      “TTL”:59,

      “data”:“95.173.136.71”

    }

],

“Comment”:“Responsefrom 194.226.127.212.”

}

Собственно, в последнем случае мы уже не имеем традиционного DNS-сервиса. Все может быть «упаковано» в пользовательское приложение (браузер или мобильное приложение). Специализированные средства DNS на компьютере конечного пользователя не нужны.

Собственно, именно этот момент и стал предметом обсуждения доклада Сары Дикенсон (SaraDickinson) на семинаре DNS-OARC. Во-первых, браузер или приложение могут сами отправлять и принимать запросы по встроенным адресам резолверов. Во-вторых, использование стандартного 443 порта существенно затруднит блокировку именно DNS-запросов. Во всяком случае, потребуется анализ TCP-пакетов. В-третьих, число DNS-провайдеров может сократиться в разы. В-четвертых, схема с корневыми удостоверяющими центрами начинает работать и для DNS.

На самом деле мы видим уплощение стека сервисов, который стремительно превращается в браузер/почтовый клиент/клиент системы мгновенных сообщений и т.п. – одним словом, в приложение. По сути, в пределе «прости-прощай», концепция открытой системы. С защитой персональных данных связан еще один вопрос, который не столь бурно обсуждается инженерным сообществом, – это необходимость передавать исходный запрос конечного клиента по всей цепочке рекурсивного поиска.

Еще в 2016 году Стефан Бортцмаер (Stephane Bortzmeyer) поднимал вопрос об отсутствии необходимости передавать полный DNS-запрос от рекурсивного резолвера всем авторитетным серверам вплоть до серверов, которые поддерживают root (корень системы DNS). Суть вопроса в том, что соответствие полного доменного имени и IP-адреса знает только авторитетный сервер той зоны, в которой установлено это соответствие. Все остальные серверы присылают только ссылки на следующий за ними сервер в рекурсивной цепочке.

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

Например, возьмем имя: Dns.example.ru

Авторитетным серверам корня нужно знать только то, что пользователи ищут что-то в зоне .ru. Передавать им полный запрос совершенно нет никакой необходимости. Но сейчас запрос передается целиком. Клуб операторов корневых серверов невелик. Правил, как войти в него, нет. Статистика запросов, которые получают авторитетные серверы, по понятным причинам является чрезвычайно ценной. Видимо, по этой же причине документ Бортцмаера широкой поддержки до сих пор не нашел, в отличие от усилий DNS-провайдинга резолвинга (Googleи CloudFlare).

Facebook и скомпрометированные аккаунты

Персональные данные могут «утекать» не только в виде «БигДаты», как это рассмотрено выше в случае с DNS. Все может быть гораздо прозаичнее. Например, 28 сентября 2018 года соцсеть Facebook объявила о том, что в результате уязвимости в режиме просмотра «View As» пострадало около 50 миллионов аккаунтов пользователей. Согласно отчету Facebook, уязвимость стала результатом совокупности трех ошибок:

Во-первых, «View As» должен быть реализован только в виде интерфейса просмотра. Однако в одном из режимов просмотра была реализована посылка видео с поздравлением ко дню рождения.

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

В-третьих, в режиме просмотра «View As» для загрузчика изображений генерировался токен доступа от лица владельца стороннего аккаунта, а не от лица владельца аккаунта, который использует режим «View As».

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

Типичное проявление «горя от ума» – нужно было попасть в чужое окружение, в котором оказался доступен и токен доступа. В настоящее время возможность «View As» отключена.

Кроме 50 миллионов пострадавших аккаунтов, Facebook переустановила токены еще 40 миллионам пользователей, которые, возможно, применяли режим «View As».

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

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

В стык с «утечкой» из Facebook оказалось еще одно событие – поломка сервиса Yale. Здесь речь уже идет не об утере персональных данных. Все гораздо интереснее. Мы имеем дело с мобильным приложением, которое управляет охраной жилища и «умными» ключами. Ключами в смысле отпирания замков, а не криптографии. Вообще, британские любители продвинутых технологий в «умных» домах оказались в сложной ситуации. Безусловно, «умные» устройства можно было открыть и закрыть при помощи предлагавшихся к ним пультов, но кто же в «умных» технологиях помнит дополнительные пин-коды.

Собственно, и случай с Facebook, и случай c Yale заставляют нас помнить, что живем мы в офлайновом мире, где информация из онлайна может быть использована отнюдь не виртуально. К слову, директива GDPR уже действует. Будет ли она применена к Facebook? Вот что интересно.

Китайцы и их чипы

И уж совсем не виртуально выглядят миниатюрные микросхемы, о которых 4 октября 2018 Блумберг опубликовал большую статью. Дело в том, что в аппаратуре Super MicroComputer Inc. были найдены чипы-закладки, которые поместили туда специально обученные китайцы.

Согласно информации агентства, все началось еще весной 2015 года, когда компания Amazon в рамках использования ее платформы AWS в целях национальной безопасности отправила несколько серверов на исследование в Канаду. Исследователи обнаружили сторонние микрочипы в серверах для министерства обороны, в аппаратуре для ЦРУ и в оборудовании для корабельных сетей ВМФ. Чипы позволяли реализовать «бэкдор» и были установлены в оборудование на заводах, а заводы эти были китайские.

Китайцы собирают комплектующие для 70% всех мобильных устройств и 90% всех персональных компьютеров. Было бы странным, если бы они не воспользовались этим своим уникальным положением в деликатных целях. По данным Блумберг, пострадало почти 30 американских компаний, включая банки, правительственные учреждения, компании-мейджоры, например, такие, как Apple и Amazon. Установить источник атаки в случае аппаратной закладки в некотором смысле проще, чем в случае с программным обеспечением.

Оборудование поставляется по накладным с определённых предприятий. Всю цепочку поставок можно проследить. Любопытно, что согласно утверждениям американских экспертов, в США существует программа контроля цепочек поставки для чувствительных областей: обороны и национальной безопасности. При этом проблема надежных поставщиков существовала всегда. И всегда экономика побеждала сомнения в надежности и безопасности поставщика.

Что же мы имеем в сухом остатке в этой истории

Во-первых, проблема импортозамещения, оказывается, актуальна не только для нас. Во-вторых, во избежание неожиданностей министерство обороны США запретило использовать сотовые телефоны производства ZTE и Huawey на американских военных объектах. В-третьих, министерство торговли США чуть было не запретило на семь лет импорт продукции ZTE в Штаты. Специалисты утверждают, что ни один частный предприниматель, а тем более частное лицо от действий китайцев не пострадали, т.к. Китай рассчитывал на отложенный эффект внедрения своих чипов. Всем остается только на это надеяться – Supermicro является крупнейшим поставщиков материнских плат в мире. Все их разом не заменишь.