Грандіозний факап. Розбираємо уразливості перевірки сертифікатів SSL і TLS в небраузерном софт
- Зміст статті Спочатку розроблений для браузерів, SSL / TLS-протокол пізніше став стандартом де-факто...
- Вийшло як завжди: перевірка провалена
- Логічні уразливості SSL / TLS-протоколу
- Продовження доступно тільки учасникам
- Варіант 2. Відкрий один матеріал
Зміст статті
Наше деловое партнерство www.banwar.org
Спочатку розроблений для браузерів, 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.
Що таке middleware-сервіси
наприклад, тут перераховано ще більше сотні вразливих мобільних додатків. У їх числі: 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). Серед інших вразливостей, якими страждає сучасна небраузерний веб-софт: використання неправильних регулярних виразів при порівнянні імені хоста; ігнорування результатів перевірки коректності сертифікату; випадкове або навмисне відключення перевірки .
Продовження доступно тільки учасникам
Варіант 1. Приєднайся до товариства «Xakep.ru», щоб читати всі матеріали на сайті
Членство в співтоваристві протягом зазначеного терміну відкриє тобі доступ до ВСІХ матеріалами «Хакера», збільшить особисту накопичувальну знижку і дозволить накопичувати професійний рейтинг Xakep Score! Детальніше
Варіант 2. Відкрий один матеріал
Зацікавила стаття, але немає можливості стати членом клубу «Xakep.ru»? Тоді цей варіант для тебе! Зверни увагу: цей спосіб підходить тільки для статей, опублікованих більше двох місяців тому.