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

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

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

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

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

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

Сейчас из некоторых российских сетей недоступны NS-ы GoDaddy, например, вот эти: ns20.domaincontrol.com, ns19.domaincontrol.com. На данные серверы имён делегировано много доменов, соответственно, как только завершится время кэширования, сайты под такими доменами станут недоступны для пользователей российских провайдеров. Из США и Европы – пока что всё работает, серверы “Премиум-DNS” GoDaddy – тоже доступны, пока что. Но, возможно, это авария, ну или ошибка в настройках маршрутизации (как обычно бывает).

Update (17/04/15): исправили; проблема наблюдалась для нескольких групп серверов, и не только для России.

Первая ступень ракеты-носителя Falcon 9 снова совершила жёсткую посадку на плавучую платформу: ступень опрокинулась после достаточно сильного удара о платформу. Но, вроде бы, дела обстоят лучше, чем в прошлый раз.

US-CERT распространил новое предупреждение об угрозе: “трансфер зоны DNS может раскрыть информацию о домене“. Это довольно странно, потому что известно очень много лет, соответственно – какая новая угроза? (В предупреждении, впрочем, сказано, что причина в большом распространении серверов, разрешающих трансфер зроны для всех желающих.)

Запросы AXFR (Asynchronous Transfer Full Range) – трансфер зоны – позволяют получить с сервера имён полный список записей в зоне DNS, то есть, фактически, увидеть все настройки адресации домена. Эти запросы используются для передачи сведений между разными авторитативными серверами, поддерживающими зону, а также в других случаях. Разумное толкование подсказывает, что все данные, публикуемые в глобальной DNS, должны являться публичными, по определению. Те не менее, доступ на трансфер зоны обычно ограничивают некоторыми доверенными серверами, чтобы не всякий мог скачать всю зону одним запросом, а только те узлы, которым это нужно. Так делается много лет.

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

Так вот теперь, похоже, нужно ждать свежего “открытия” “угрозы” раскрытия списка имён доменной зоны через NSEC в технологии DNSSEC. Хотя, DNSSEC пока что не имеет должного распространения.

Существуют EV-сертификаты для TLS. Это сертификаты с расширенной проверкой организации, для домена которой выпускается сертификат. Технически, они такие же, как и обычные, но красят адресную строку в некоторых браузерах в зелёный цвет. Теперь для EV-сертификатов нужна поддержка Certificate Transparency (согласно рекомендациям разработчиков браузеров; сейчас требование актуально только для линейки Google Chrome). Посмотрим, как это выглядит на практике, для пользователя браузера Chrome (англоязычный интерфейс). Для примера я возьму сайт интернет-банка “Альфа-банка”. Сведения о статусе аудита Certificate Transparency (CT) отображаются в выпадающем окошке, по клику на название организации в адресной строке браузера:

Наличие строки Transparency information говорит о том, что в сертификате содержатся записи из логов CT. По клику открывается окно с дополнительной информацией:

О чём данные из этого окна говорят типичному пользователю? Да, к сожалению, ни о чём. Разобраться в них сложнее, чем в структуре сертификата, потому что для понимания требуется знание того, как работает технология CT. Ну, разве что, можно обратить внимание на то, что указана дата, когда сертификат был внесён в лог (в нашем случае эта дата совпадает с датой начала действия сертификата), да и на то, что наличие сертификата в логе подтверждено подписями (статус Verified), а это означает, что данный сертификат, скорее всего, был действительно выпущен для указанного сервера, согласно соответствующим процедурам.

Сведения о включении сертифката в лог CT содержатся в самом сертификате, для этого в расширения X.509 внесено специальное поле:

Пока что технология CT не очень распространена, но поддержка ведущими браузерами и требование по наличию этой технологии в дорогих EV-сертификатах (а в дальнейшем, очевидно, во всех типах сертификатов, используемых на веб-узлах), должны сделать её популярной и обязательной.

Сейчас корни китайского УЦ CNNIC не поддерживается браузерами (Chrome и Firefox) в полном объёме, это результат истории с выпуском “перехватывающих” промежуточных сертификатов. Google ставит в качестве условия возврата доверия CNNIC-у – полную поддержку Certificate Transparency (CT). Интересно, что если CNNIC такую поддержку реализует, то это будет первый УЦ, который реализовал CT в полном масштабе даже не потому, что есть RFC, а лишь под давлением разработчиков браузеров.

Ко Дню космонавтики – традиционное изображение ракеты. Советская почтовая марка из 1972 года:

Подробное описание уязвимости CVE-2015-1130 в Apple OS X и истории её обнаружения, с примерами кода. Уязвимость позволяет произвольному пользователю получить файл, исполняемый на локальной машине с правами root. Для эскалации привилегий используется системный API, в котором содержится ошибка. Пишут, что уязвимость существовала как минимум с 2011 года.

В домене .ORG доступны однобуквенные имена. Отличный пример: X.ORG (там есть соответствующий сайт, конечно же). Это довольно дорогие доменные имена. Похоже, что в апреле домен i.org приобрёл некоторую связь с Facebook – как минимум, на это указывают записи Whois (почему-то, с минусом, да):

$ whois i.org | grep ‘Organization’
Registrant Organization:-Facebook
Admin Organization:-Facebook
Tech Organization:-Facebook

Домен делегирован на серверы a.ns.facebook.com и b.ns.facebook.com, которые, впрочем, на запросы об этом имени не отвечают (просто молчат в ответ по UDP, а по TCP – эти сервера имён вообще разговаривать сразу отказываются).

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

Здравствуйте!

На странице http://help.yandex.ru/images/indexing.xml сказано, что поиск Яндекса по картинкам не поддерживает HTTPS. Точнее, для индексации файла картинки требуется, чтобы файл было доступен по HTTP. Сейчас веб-сайты массово переходят на защищённый протокол (более того, TLS является основным рекомендованным транспортом в HTTP/2). В идеале, весь контент современного веб-сайта должен передаваться веб-сервером по HTTPS, это касается и картинок, потому что “вынос” изображений в открытый протокол HTTP несёт с собой риски возникновения проблем с безопасным доступном к сайту в целом, так как предоставляет возможности для “деградации” протокола при доступе к определённым URL.

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

Спустя три дня получил лаконичный ответ от Платона Щукина:

Здравствуйте, Александр!

Эта ситуация уже исправлена. Картинки индексируются по https.

Неплохо, если так, хотя и противоречит описанию на сайте. Что ж, ждём обновления индекса.