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

Осенью прошлого года у большой штатовской торговой компании – Target – случилась утечка данных. Утекли дампы платёжных карт клиентов. Дампы собирались в POS-терминалах, заражённых специальным ПО, а позже переправлялись наружу, как говорят, через пару захваченных узлов внутри сети Target. История шумная.

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

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

Да, так оно обычно бывает.

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

То, что заявлена поддержка VPN, не означает, что трафик защищён от перехвата провайдером этого VPN. Соответственно, если вы заходите через некий “бесплатный VPN-анонимайзер” на livejournal.com (или в другой веб-сервис, например, в веб-почту), то кто-то может утащить ваш пароль. Более того, вероятен перехват HTTPS – проверено на практике: многие не утруждают себя чтением и пониманием предупреждений систем безопасности браузеров, а сразу нажимают “Всё равно продолжить”. Хуже того, злонамеренные узлы могут проводить инъекцию кода в веб-страницы, что также ведёт к утечкам важных данных. По факту, риски здесь более опасные, чем некая “блокировка доступа” к той или иной страничке. (TOR-клиенты я бы тоже не рекомендовал – это не VPN, а лишь средство анонимизации; TOR-трафик тоже подвержен перехвату на выходных узлах.)

Если нужно использовать VPN, то либо настройте свой (это не так сложно; например, вот описание настройки VPN c использованием Amazon EC2), либо приобретите подписку у более или менее проверенного провайдера VPN. Сейчас VPN штатно поддерживается всеми распространёнными операционными системами.

На сайте Ruward.ru публикуют некое исследование безопасности CMS, сравнивают коробочные (коммерческие) CMS и бесплатные CMS. Методика не ясна, но это другой разговор (с методиками вообще проблема в исследованиях, как известно).

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

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

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

Вот.

Занимательная реализация офлайновой криптосистемы: с сайта получаем специальные распечатки (таблицы), с помощью которых проводится зашифрование и расшифрование коротких сообщений. (Update: на странице по ссылке есть инструкции и интерфейс, для получения готовых PDF-файлов с шифровальными таблицами. Update 2: сайт более не доступен.) Реализуется схема, известная как шифр Вернама (или схема одноразовых блокнотов). Каждый ключ используется один раз. Интересно для детей, интересующихся криптографией.

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

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

Новый сайт Sochi2014.com вполне логично размещён на мощностях Akamai (один из крупнейших мировых провайдеров услуг CDN) – это хорошо. Но вот с HTTPS повторяется типичная для Akamai история: при попытке безопасного соединения с https://www.sochi2014.com/ – серверы отдают “провайдерские” SSL-сертификаты, выпущенные не для sochi2014.com, а для имён вроде *.akamaihd.net, a248.e.akamai.net и прочих. В результате – имеем в браузере предупреждение системы безопасности, что уже не очень хорошо.

Проблема, кстати, весьма старая, и Akamai её, похоже, так и не поправил.

Сейчас в Сети массово внедряются новые домены верхнего уровня, с самыми разными именами (.link, .moscow, .shop и др. – список можно посмотреть на специальной странице). Уже на этапе обсуждения технических аспектов появления новых строк в корневой зоне DNS, возникли опасения, что возможен конфликт имён, так как некоторые корпоративные сети используют собственные, “локальные”, домены верхнего уровня, выбирая их произвольно. Примеры: .corp, .lan и так далее.

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

ICANN (организация, управляющая адресацией Интернета) решила зарезервировать в новых доменах имена второго уровня, которые наблюдались в трафике корневых серверов за некоторый промежуток времени. То есть, регистрация таких имён будет, как минимум в течение некоторого времени, невозможна. Резервирование должны осуществить администраторы соответствующих новых доменных зон. Cписки резервируемых имён опубликованы ICANN в соответствующих разделах сайта. Вот, например, список для .link (длинный, 34377 строк), а вот – для кириллического домена .дети (всего несколько десятков строк). Для домена moscow – резервируются 6236 строк.

Если взглянуть на приведённые списки, то, помимо редких осмысленных сочетаний символов, можно обнаружить большое количество строк, представляющих собой случайную последовательность из десяти букв, например: fnszofchcm. Судя по всему, это следы работы функций проверки DNS-окружения браузеров Chrome и Chromium (и некоторых других): запросы, содержащие случайные комбинации символов, выполняются для того, чтобы убедиться, что имеющийся в сетевом окружении DNS-резолвер не подменяет несуществующие адреса – в ответ на запрос о несуществующем в глобальной DNS имени должен приходить ответ, что такого имени не существует (банальность, казалось бы, но в реальности это не всегда так).

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

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

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

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

На сайте Der Spiegel опубликовано несколько материалов о специальном направлении внутри АНБ, которое занимается решением задач “целевого проникновения” в различные информационные системы (TAO – Tailored Access Operations). Вообще, речь там идёт о технических средствах разного назначения и различной степени специализации: упоминаются и устройства, предназначенные для дистанционного съёма информации через электромагнитные утечки, и специальные базовые станции GSM, для перехвата телефонных переговоров, и замаскированные анализаторы радиоэфира, и много всего другого. Есть и чисто программные средства (“трояны”).

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

Каких-то удивительных устройств или революционных решений, о которых ничего не было слышно ранее, в материалах Der Spiegel нет. Но подборка весьма занятная, так или иначе. Особенно интересно внимание, которое уделяется технике преодоления периметра в случае физически изолированных компьютерных систем (в англоязычной литературе – air gap; буквально: “воздушный зазор”). В качестве решения предлагаются аппаратные закладки, формирующие радиоканал, по которому происходит утечка информации: то есть, “неподключенный к Интернету” отдельный компьютер – оказывается к этому Интернету подключен против воли владельца, через соседний такой же физический сервер, у которого канал в глобальную сеть имеется. Для этого оба сервера должны быть оснащены специальными “радиозакладками” от АНБ.

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

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

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

Прослушать и “раскодировать” по звуку нажимаемые кнопки – возможно, это уже не раз демонстрировалось на практике. В случае с паролями есть дополнительные трудности. Дело в том, что для различения акустических сигнатур нажимаемых кнопок клавиатуры удобно использовать словарь, при этом атакуемый пользователь должен набирать текст на соответствующем, известном языке. Алгоритм довольно простой, он основан на различной частотности сочетаний символов и совпадает с криптоанализом наивных шифров замены; в случае с клавиатурой, символы из “секретного алфавита” замены – это уникальные сигнатуры кнопок. Но пароли – это не текст на естественном языке: в них больше энтропии, кроме того, они относительно короткие. Последний момент, кстати, заметно мешает проверке собранных сигнатур по словарю паролей.

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

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

Возможно, такие приложения уже где-то есть.

Reuters сообщает, что компания RSA Security несколько лет назад заключила с NSA контракт, согласно которому в криптографических продуктах RSA предпочтение должно было отдаваться алгоритму генератора псевдослучайных чисел Dual EC DRBG. Последний содержит потенциальный бэкдор, который хоть и оказался плохо спрятан, но неплохо сконструирован в смысле его использования в роли защищённого мастер-ключа.

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

Есть более изящный способ: удостоверяющие центры используют для генерации и работы с корневыми ключами специальную аппаратуру (HSM – Hardware Security Module); предложим УЦ приобрести сертифицированную аппаратуру, использующую заданный генератор псевдослучайных чисел – теперь, с помощью мастер-ключа, можно за разумное время вычислить секретный ключ УЦ, не нанося прямого вреда его репутации. Задача перехвата HTTPS решена.

(Забавно, кстати, что на сайте www.rsa.com используется кривой SSL-сертификат, выпущенный для *.emc.com – RSA Security ранее была приобретена EMC Corporation: видимо, попытка сделать HTTP-редирект через кривой сертификат, является одним из результатов слияния компаний.)

(Продолжаем криптографическую серию заметок.) Оказывается, в Firefox версии 26 включили поддержку OCSP staplig. Что это такое? OCSP (Online Certificate Status Protocol) – это протокол, позволяющий клиенту (браузеру) в режиме онлайн проверить не был ли представленный сервером SSL-сертификат отозван. Напомню, что отзыв сертификата – это специальная процедура, позволяющая исключить из списка доверенных сертификат, срок действия которого ещё не истёк. Это требуется, например, в том случае, если скомпрометирован закрытый ключ, соответствующий сертификату.

Логика OCSP довольно проста: получив сертификат, браузер обращается с запросом, содержащим серийный номер сертификата, по адресу специального ответчика (“респондера”), обычно работающего на серверах удостоверяющего центра (УЦ), и может получить ответ о том, не отозван ли этот сертификат. А может и не получить – дело в том, что ответчики OSCP некоторых УЦ работают не так надёжно, как хотелось бы. У OCSP есть и ещё одна особенность: владельцы ответчика получают информацию о том, какие пользователи ходят на сайты, где установлены соответствующие сертификаты (очевидно, что эту информацию передают браузеры, запрашивающие проверку отзыва сертификата).

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

Я некоторое время назад наладил демонстрационный сервер под доменом 1d.pw, там поддерживается и OCSP stapling – только сертификат там не EV, а простой. Посмотреть на работу OCSP stapling можно при помощи OpenSSL, вот так:

$ openssl s_client -connect 1d.pw:443 -tlsextdebug -status

В выдаче отыскиваем строки, следующие за “OCSP response”:

OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)