казывается, не только разработчики Android-приложений грешат неграмотным внедрением SSL, но подобные ошибки присутствуют в программах ведущих софтверных компаний, включая Amazon и Paypal.
Неграмотная процедура проверки SSL-сертификатов обнаружена в
критически важных приложениях, SDK, Java middleware, банковском софте и
т.д., что открывает перед злоумышленниками возможности для MiTM-атаки —
ничего хуже этого и представить невозможно, считают исследователи из
Стэнфордского и Техасского университетов, которые опубликовали научную
работу «Самый опасный код в мире: проверка SSL-сертификатов вне браузера».
Достоин упоминания тот факт, что группа американских учёных работала
под руководством Ph.D. Техасского университета Виталия Шматикова.
Итак, исследователи обнаружили некорректную процедуру SSL-валидации в ряде очень серьёзных программ:
- Java-библиотека Amazon EC2 и все облачные клиенты на её основе;
- SDK Amazon и SDK Paypal, которые отвечают за передачу платёжных данных от торговой площадки к платёжному гейту;
- движки интернет-магазинов osCommerce, ZenCart, Ubercart и PrestaShop;
- код AdMob в мобильных веб-сайтах;
- мобильное приложение банка Chase и некоторые другие приложения и библиотеки под Android;
- Java middleware для веб-сервисов, включая Apache Axis, Axis 2,
Codehaus XFire и библиотеку Pusher для Android, а также все приложения,
которые используют перечисленное middleware.
В качестве примера безалаберности можно привести фрагмент исходного кода банковского приложения Chase.
public final void checkServerTrusted(X509Certificate[]
paramArrayOfX509Certificate, String paramString)
{
if ((paramArrayOfX509Certificate != null) && (
paramArrayOfX509Certificate.length == 1))
paramArrayOfX509Certificate[0].checkValidity()
while (true)
{
return;
this.a.checkServerTrusted(
paramArrayOfX509Certificate, paramString)
}
}
Любое SSL-соединение, установленное каждой из перечисленных программ,
не является безопасным. Ключевая проблема лежит не столько в низкой
квалификации разработчиков, сколько в плохом дизайне программных
интерфейсов для реализации SSL (таких как JSSE, OpenSSL и GnuTLS) и
библиотек для передачи данных (таких как cURL). Эти API и библиотеки
сложны для обычного программиста, предлагая ему слишком путаный набор
настроек и опций.
Например, в cURL есть несколько параметров для CURL_SSL_VERIFYHOST . Параметр VERIFYHOST=0 интуитивно понятен: он отключает проверку сертификата. Параметр VERIFYHOST=2
выполняет корректную проверку и сверяет имя хоста, указанное в
сертификате, с именем хоста, который предъявляет сертификат. А вот
параметр VERIFYHOST=1 (VERIFYHOST=TRUE ) делает нечто очень странное: он проверяет, что сертификат принадлежит какому-то хосту, а затем принимает его от любого хоста. Понятно, что многие программисты не ожидали от cURL такой «подставы». Кстати, разработчик cURL Дэниел Стенберг вчера уже высказался по этому поводу. Ему после 10+ лет работы над cURL очень обидно слышать подобные обвинения, тем более что за все эти годы никто ни разу не предлагал изменить параметры для CURL_SSL_VERIFYHOST .
По результатам анализа ситуации с реализацией SSL в различных
приложениях Шматиков с коллегами выработали ряд рекомендаций, в том
числе они рекомендуют использовать специальное программное обеспечение
для проверки корректности программного кода и пентестинга: например,
программа TLSPretense. Есть также чёткая инструкция, как реализовать проверку SSL-сертификатов с помощью OpenSSL и репозиторий примеров правильного кода SSL Conservatory.
|