Грандиозный факап. Разбираем уязвимости проверки сертификатов SSL/TLS в небраузерном софте

Содержание статьи

• Хотели как лучше
• Получилось как всегда: проверка провалена
• Логические уязвимости SSL/TLS-протокола
• Другие распространенные уязвимости реализации SSL/TLS-протокола
• Корень зла SSL/TLS
• Ложка меда в бочку дегтя

Первоначально разработанный для браузеров, SSL/TLS-протокол позже стал стандартом де-факто вообще для всех защищенных интернет-коммуникаций. Сейчас он используется для удаленного администрирования виртуальной инфраструктуры, развернутой в облаке, для передачи платежных реквизитов покупателя от серверов электронной коммерции к платежным процессорам, таким как PayPal и Amazon, для пересылки локальных данных в облачное хранилище, сохранения переписки в мессенджерах и аутентификации серверов в мобильных приложениях iOS и Android. Как видишь, список ситуаций, когда обмен весьма чувствительной информацией требует максимальной безопасности, довольно внушителен. В этой статье мы рассмотрим, как безопасность этих коммуникаций обеспечивается на практике.

Хотели как лучше

В теории, защищенное SSL/TLS-протоколом соединение должно обеспечивать конфиденциальность, достоверность и целостность коммуникаций клиентского и серверного софта, даже если в сеть проник активный продвинутый злоумышленник: когда сеть полностью захвачена врагом, DNS отравлен, а точки доступа и маршрутизаторы, коммутаторы и Wi-Fi контролируются злоумышленником, который, помимо всего прочего, контролирует SSL/TLS-бэкенд. Кроме того, когда клиентский софт пытается подключиться к законному серверу, злоумышленник может подменить сетевой адрес сервера (например, через отравление DNS) и перенаправить клиент вместо законного сервера на свой злонамеренный сервер.

Безопасность коммуникаций в таких суровых условиях, как известно, целиком зависит от адекватности проверки криптографического сертификата, предоставленного сервером при установке соединения. В том числе от адекватности реализации набора шифров (cipher suite), которыми клиент и сервер пользуются при обмене данными. Для того чтобы SSL/TLS-соединение было полностью безопасным, клиентский софт в числе прочего должен тщательно удостовериться в том, что:

• сертификат выдан действующим органом сертификации;
• срок его действия не истек (или сертификат не был отозван);
• в списке перечисленных в сертификате имен присутствует тот домен, к которому производится подключение.

Получилось как всегда: проверка провалена

Однако во многих приложениях и библиотеках, для которых безопасность коммуникаций очень критична, процедура проверки SSL/TLS-сертификата, и даже EV-SSL, сертификата с расширенной проверкой, полностью провальна, причем это справедливо для всех популярных операционных систем: Linux, Windows, Android и iOS. Среди уязвимого софта, библиотек и middleware-сервисов можно выделить следующие:

• Amazon’овская Java-библиотека EC2 и все облачные фронтенд-клиенты, построенные на ее основе;
• Amazon’овский и PayPal’овский торговый SDK, ответственный за доставку платежных реквизитов от сайтов (на которых развернута инфраструктура онлайн-коммерции) к платежным шлюзам;
• интегрированные «корзины», такие как osCommerce, ZenCart, Ubercart и PrestaShop, которые не проверяют сертификаты вообще;
• AdMob-код, используемый мобильным софтом для показа контекстной рекламы;
• интерфейсные фронтенд-компоненты ElephantDrive и FilesAnywhere, ответственные за взаимодействие с облачным хранилищем;
• Android’ная библиотека Pusher и весь софт, который использует Pusher API для управления обменом мгновенными сообщениями (например, GitHub’овский Gaug.es);
• Apache HttpClient (версия 3.x), Apache Libcloud и все клиентские подключения к серверам Apache ActiveMQ и подобным;
• SOAP middleware-сервисы Java, в том числе Apache Axis, Axis 2, Codehaus XFire; а также весь софт, который на базе этих middleware-сервисов построен;
• API-инструменты Elastic Load Balancing;
• Weberknecht-реализация WebSockets’ов;
• а также весь мобильный софт, построенный на базе перечисленных выше библиотек и middleware-сервисов (чтобы понять, что такое middleware-сервисы, смотри слайды); в том числе iOS-клиент хостинг-провайдера Rackspace.

Например, здесь перечислено еще больше сотни уязвимых мобильных приложений. В их числе: Android’s Google Cloud Messaging, Angie’s List Business Center Passwords, AT&T Global Network Client, CapitalOne Spark Pay, Cisco OnPlus (remote access), Cisco Technical Support, Cisco WebEx, Cisco WebEx Passwords, Dominos Pizza, E-Trade, Freelancer, Google Earth, Huntington Mobile (Bank), Intuit Tax Online Accountant, iTunes Connect, Microsoft Skype, Oracle Now, Pinterest, SafeNet (VPN client), SouthWest Airlines, Uber, US Bank — Access Online, Western Union, WordPress, Yahoo! Finance, Yahoo! Mail.

Логические уязвимости SSL/TLS-протокола

SSL/TLS-соединения всего этого и многого другого софта уязвимы для широкого спектра MitM-атак. При этом MitM-атаку можно провести зачастую даже без подделки сертификатов и без похищения приватных ключей, которыми серверы подписывают свои сертификаты. MitM-атаку можно провести, просто эксплуатируя логические уязвимости, которые присутствуют в процедуре проверки SSL/TLS-сертификата на стороне клиентского софта. В результате MitM-злоумышленник может, например, собирать токены авторизации, номера кредитных карт, имена, адреса и прочее — у любого продавца, который использует уязвимые веб-приложения обработки платежей.

Поставщики мобильного софта, которые берут за основу семпл-код AdMob для связи своих приложений с AdMob-аккаунтом, тоже уязвимы — они позволяют атакующему захватывать учетные данные и получать доступ ко всем его Google-сервисам. К примеру, из-за некорректной проверки сертификатов в таких мессенджерах, как Trillian и AIM, MitM-злоумышленник может похитить учетные данные для входа ко всем сервисам Google (включая Gmail), Yahoo и также к сервисам Windows Live (в том числе SkyDrive). Среди других уязвимостей, которыми страдает современный небраузерный веб-софт: использование неправильных регулярных выражений при сравнении имени хоста; игнорирование результатов проверки корректности сертификата; случайное или преднамеренное отключение проверки.

Продолжение доступно только подписчикам

Материалы из последних выпусков можно покупать отдельно только через два месяца после публикации. Чтобы продолжить чтение, необходимо купить подписку.

Подпишись на «Хакер» по выгодной цене!

Подписка позволит тебе в течение указанного срока читать ВСЕ платные материалы сайта. Мы принимаем оплату банковскими картами, электронными деньгами и переводами со счетов мобильных операторов. Подробнее о подписке

Уже подписан?

Источник