dxdt.blog: занимательный интернет-журнал

Спрашивают, зачем нужно использовать протокол HTTPS для веб-сайта, если последний не работает с конфиденциальной информацией (например, это не панель управления хостингом). Казалось бы – если на страницах нет ничего секретного, то зачем их шифровать? Такая типичная ошибка в восприятии HTTPS как протокола, нужного исключительно для шифрования (к сожалению, такая искажённая картина весьма распространена). Действительно, шифровать не обязательно, но HTTPS это не только и не столько шифрование, сколько контроль целостности. То есть, безопасный протокол защищает страницы от подмены.

Если у вас сайт банка, но “общие” страницы отдаются по HTTP, а не по HTTPS, это означает, что кто-то может легко подменить часть кода веб-страницы на пути к пользовательскому компьютеру (или заменить всю страницу). Такая подмена позволяет внести изменения в тексты на странице (скажем, сообщить об “отзыве” лицензии), при этом у пользователя нет никаких инструментов, позволяющих проверить, получает ли он информацию в неизменном виде.

HTTPS решает эти проблемы: изменить страницы на промежуточном узле простым способом не получится (что, естественно, не отменяет возможного перехвата HTTPS, но переводит задачу на принципиально иной уровень сложности). Конечно, всегда остаётся доступен старый способ: принудительная замена протокола на стороне пользователя, которая хорошо работает для ссылок (простая замена https:// на http://). Однако если пользователь привык заходить на сайт банка по браузерной закладке (типичный сценарий, кстати), попытка подмены протокола, – например, через редирект, – вызовет предупреждение в браузере (потому что для выполнения HTTP-редиректа тоже потребуется серверный SSL-сертификат, а его, скорее всего, у перехватывающего соединение узла нет).

И не стоит забывать о том, что уже есть поддерживаемые браузерами инструменты, позволяющие жёстко назначить HTTPS единственным протоколом для веб-сайта. Пример: HTTP Strict Transport Security.

В Wired публикуют статью о том, что спецслужбы США (АНБ, в основном) не собирают больших справочных баз данных по уязвимостям в ПО, неизвестным широкой общественности. Речь идёт о практике публикации (или, наоборот, сокрытия) информации об уязвимостях, которые находят аналитики АНБ (и других профильных агентств). Если уязвимость сохраняется в секрете, то её можно длительное время использовать для атак на информационные системы. Однако от этой же уязвимости, как пишут, могут пострадать информационные системы США – то есть, лучше бы её опубликовать, чтобы разработчики заткнули дыру. Такая дилемма.

Вообще, можно, конечно, предположить, что таких государственных баз данных нет, но не ясно, как, в таком случае, работают аналитические подразделения АНБ. Ведь если каждый раз, когда уязвимость обнаружена, о ней бы сообщали разработчикам ПО, это повлекло бы за собой утечку информации о том, с чем работает данная служба. Особенно интересной представляется ситуация, когда уязвимость обнаружена в иностранном ПО (или в каком-нибудь иностранном оборудовании). Хотя, конечно, в Штатах такое положение дел встречается не так уж часто.

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

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

Вообще, концепция подобного “неподключения” известна давно, называется она air gap (“воздушный зазор”, в вольном переводе) и применяется в целях обеспечения информационной безопасности, иногда – весьма эффективно применяется. Однако описанная выше наивная трактовка концепции, подразумевающая использование флешки, лишь создаёт дополнительные риски: флешка обязательно теряется (или, хоть это и маловероятно, её крадут) – получаем потенциальный канал утечки. Конечно, нельзя забывать и о том, что современное вредоносное ПО успешно распространяется как раз при помощи флешек. Соответственно, “продвинутый пользователь”, постоянно путешествующий со своей флешкой по разным устройствам, не только подвергает свой собственный компьютер угрозе заражения каким-нибудь зловредом, но ещё и служит транспортом для этих зловредов внутри предприятия. Риск внедрения вредоноса на компьютер через вычислительную сеть – едва ли выше, чем в случае с флешкой. Кстати, как писали аудиторы, нашумевший Stuxnet был занесён на режимный иранский завод именно по такой схеме: флешка с данными и документами.

(На правах технократического юмора.) Если кто не знает, то “циска” – это собирательное название маршрутизаторов, произошедшее от Cisco и почти ставшее нарицательным. Известно, что если отключить достаточное число маршрутизаторов, то национальный сегмент Интернета потеряет внутреннюю связность (а не только связность с глобальной Сетью). То есть внешняя атака, отключающая “циски”, приводит к пропаданию Интернета в выбранной стране. Естественно, маршрутизаторы содержат уязвимости-закладки, некоторые из них позволяют маршрутизатор не просто отключить, а убить совсем. Идеальным решением задачи активации закладки является передача в составе трафика специального ключа.

Маршрутизаторы копируют все пакеты и обязательно анализируют часть их заголовков, а факультативно – содержимое самих пакетов. Так что обнаружив ключ активации в составе полученного пакета данных, маршрутизатор отключается. Ключ может представлять собой строку из 256 бит, соответственно подобрать его не представляется возможным. Понятно, что программная реализация проверки валидности полученного кода должна быть устроена так, что сам код на основании анализа алгоритма вычислить не удастся. Это очень важный аспект: иначе кто-то сможет получить ключ уничтожения в своё распоряжение, прикупив одну уязвимую “циску”.

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

Предположим, что пакет, содержащий “смертельный код”, отправляется внешним узлом в направлении ближайшего пограничного маршрутизатора атакуемого сегмента сети. Если маршрутизатор, получив пакет, умирает немедленно, то гарантировать можно лишь уничтожение этого самого маршрутизатора – остальные узлы-маршрутизаторы останутся работоспособными, а вот связь их с внешним сетевым миром прервётся, поэтому вырубить их извне уже не получится. Проблема.

Допустим, маршрутизатор сперва отправляет пакет далее по маршруту, и лишь потом – умирает. При такой схеме возможно вывести из строя один из маршрутов, в который входит начальный маршрутизатор, да и то – гарантировать ничего нельзя: пакет может потеряться в пути, а переслать его повторно будет уже некому. Так как маршрутов доставки пакетов обычно несколько, получаем проблему с покрытием: после того, как откажет несколько “цисок”, эпидемия затихнет, а связность сохранится.

Естественно, можно продолжать бомбардировать все доступные узлы пакетом, содержащим смертельный код, но есть и другое решение. Для качественного уничтожения связности пакеты должны пройти через каждый маршрутизатор, обеспечивающий работу национального сегмента Сети. При этом желательно, чтобы вредоносные пакеты вообще не покидали пределов сегмента. Это означает, что источником пакетов должны быть пользовательские компьютеры – тогда они заведомо охватят большое число маршрутизаторов, а распространяться эпидемия отключений начнёт с самого подходящего уровня: ведь без конечных пользователей Интернет не имеет особого смысла.

Как получить нужный эффект? Например, использовать механизм, встроенный в распространённую операционную систему. Пусть в определённый момент центральные серверы, куда эта операционная система обращается за обновлениями, отправят некий “праймер” – сигнал к атаке. После этого операционная система в любой пакет исходящего трафика встраивает убивающий маршрутизаторы код и – вуаля, сегмент посыпался, причём падают маршрутизаторы во всех возможных путях доставки пакетов к пользователям, покрытие идеальное. Естественно, операционная система пользовательских компьютеров не содержит секретного кода: он передаётся центральными серверами, в зашифрованном виде, чтобы не вызвать преждевременного срабатывания. От конечного компьютера требуется только расшифровать код и вернуть его обратно в Сеть – самая обычная операция, кстати, не вызывает подозрений, встречается во многих протоколах, так как может являться чем-то вроде проверки электронной подписи или служить частью системы аутентификации.

А после того как в национальном сегменте умерли хотя бы две трети “цисок”, на восстановление связности потребуются многие месяцы (не исключено, что и годы).

Продолжается новомодный поток анонсов с громкими атаками на SSL/TLS: в этот раз – POODLE, позволяющая свести на нет секретность HTTPS (например) при использовании SSLv3. Занятно, что в сообщении по ссылке читаем: “Today, Firefox uses SSLv3 for only about 0.3% of HTTPS connections” (“Сейчас Firefox использует SSLv3 лишь для 0,3% HTTPS-соединений”).

(Подробное описание, PDF.)

Большой проблемой современного состояния SSL/TLS в Интернете является возможная “прозрачная” подмена сертификатов, проводимая при участии удостоверяющих центров. Одним из решений этой проблемы является построение независимой от иерархии удостоверяющих центров публичной системы аудита выданных сертификатов. Соответствующая инициатива называется Certificate Transparency (CT), я писал о ней примерно год назад. Результаты аудита, которые публикуются в специальных логах, могут, в том числе, автоматически проверяться браузерами. Технология активно развивается и уже частично поддерживается браузерами Chrome и Chromium. Конечно, есть проблема с полнотой логов, но важно, что поддержку включили.

Кстати, поговаривают, что в Chrome/Chromium будут требовать поддержки CT для EV-сертификатов (сертификатов с “дополнительной валидацией”) с февраля 2015 года. То есть, уже совсем скоро.

Посмотреть, как работает эта новая технология, можно, например, здесь: https://embed.ct.digicert.com/.

Кстати, я не так давно писал, что гипотетически возможен вариант с “внешним отключением Интернета“. Однако, насколько можно судить, сейчас в новостях речь идёт не просто об отключении Рунета, а о том, чтобы получить возможность всё же использовать Интернет, в том случае, если от него пытаются отключить внешние силы.

Вообще, разумными представляются действия, направленные на сохранение присутствия в глобальной Сети, вне зависимости от внешних попыток отключения. Действующая сейчас глобальная инфраструктура, конечно, создаёт тут весьма заметные трудности, но их можно и преодолеть. Неотключаемый (для всех) Интернет – был бы наиболее интересен. Однако, он, пока что, невозможен.

Технически, сломать национальный сегмент можно, если ломающая сторона обладает достаточными полномочиями и ресурсами. Тут сомнений быть не может. Ломать, естественно, нужно не на уровне DNS, а на уровне BGP (то есть, на уровне маршрутизации). Если у вас не работает BGP, то национальный сегмент разваливается на множество автономных систем, которые не могут обмениваться трафиком. То есть, нет даже единого интранета. Естественно, DNS при этом тоже не работает. Но локальные сети – остаются. Также, остаётся “локальный” обмен трафиком, если между несколькими автономными системами установлены прямые подключения (“пиры”). Например, у “Яндекса” есть прямые каналы к крупным российским хостингам (возможно, и к зарубежным). Эти каналы не видны для всего остального Интернета. (Не видны – в терминах BGP.)

(Очень интересно будет вспомнить, что отключение Интернета в Сирии, если верить иностранной прессе, произошло из-за ошибки сотрудников АНБ, которые удалённо ковырялись в пограничном маршрутизаторе и – сломали его. Медийное пространство хорошо выстроено, да.)

В 2012 году в Сирии случилась глобальная телекоммуникационная авария, и местные сети (автономные системы) пропали из Интернета. Теперь Эдвард Сноуден рассказывает, что это случилось в результате неудачной операции АНБ по перехвату трафика в сирийском сегменте. Подразделение агентства пыталось удалённо внедрить в программное обеспечение маршрутизатора (Cisco, небось) “дополнительную нагрузку”, но специалисты ошиблись и просто сломали маршрутизатор (такое случается, сложно поспорить). Занятное развитие истории.

Очень занимательная атака: используя подмену путей BGP (routing hijacking), злоумышленники перехватывали результаты работы “майнеров” Bitcoin, которые участвовали в пулах. Напомню, что пулы – это объединения пользователей, которые добывают биткоины. Так как для реализации пулов используется незащищённый протокол, атакующие смогли перенаправлять трафик, адресованный центру, распределяющему задачи по “майнерам”, на свои сервера. Перенаправление проводилось с использованием BGP, на провайдерском уровне. Предметом атаки являлось несколько пулов. Таким образом, результаты добычи биткоинов доставались тем, кто управлял перехватывающими трафик узлами, которые, фактически, отъедали часть мощностей пула. (Подробности – по ссылке выше.)

Доктайп HTML5 стал самым распространённым на веб-узлах Рунета, потеснив XHTML 1.0 Transitional. Строго говоря, это не означает, что HTML5 стал самым распространённым языком разметки: на страницах с доктайпом HTML5 всё равно используются элементы, упразднённые в этом стандарте. Однако популярность HTML5 сильно выросла, а пережитки прошлых стандартов будут встречаться на сайтах ещё долго – тут уж ничего не поделаешь.

Заработал nic.yandex. А www.yandex, почему-то, ещё не сделали. Странно.