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

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

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

В теории, защищенное 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). Среди?других уязвимостей, которыми страдает современный небраузерный веб-софт: использование неправильных регулярных выражений при сравнении имени хоста; игнорирование результатов проверки корректности сертификата; случайное или преднамеренное отключение проверки.

Теги: CSS, проверки коммуникаций Cisco числе сертификатов