100 Мифы и заблуждения информационной безопасности Лукацкий
| Вид материала | Документы |
СодержаниеМиф №89 «Шифрование по SSL обеспечивает защиту транзакций в Интернет-банке»06.09.2010 02:40 |
- Аннотация, 418.67kb.
- Е. А. Свирский Рассматриваются вопросы работы курсов повышения квалификации по информационной, 67.93kb.
- Система менеджмента информационной безопасности, 205.89kb.
- Теоретические основы информационной безопасности автоматизированных систем, 26.65kb.
- Содержание курса. Урок, 902.96kb.
- Обеспечение информационной безопасности организации как метод антикризисного управления, 54.18kb.
- Мифы Древней Греции Мифы Древней Индии Мифы древних славян Мифы североамериканских, 33.93kb.
- «Комплексные системы информационной безопасности», 260.23kb.
- Вопросы по информационной безопасности, 268.68kb.
- Рекомендации по обеспечению информационной безопасности Заключение, 358.69kb.
Миф №89 «Шифрование по SSL обеспечивает защиту транзакций в Интернет-банке»06.09.2010 02:40
Алексей Лукацкий - менеджер по развитию бизнеса Cisco Systems
Одним из основных способов защиты транзакций в Интернет-банкинге является использование шифрования. Одной из основных рекомендаций является применение протокола SSL (или TLS). Например, на сайте Альфа-Банка написано следующее: «Проверяйте, что соединение действительно происходит в защищенном режиме SSL, в правом нижнем углу Вашего вэб-браузера должен быть виден значок закрытого замка». Но действительно ли шифрование по SSL обеспечивает должный уровень защиты? Нет ли тут какого-нибудь подвоха?
Начну с того, что обычное шифрование между клиентом и банком никогда не служило гарантией надежных транзакций. Специалистам давно известна атака «человек посередине» (man-in-the-middle), которая заключается в том, что злоумышленник располагается между клиентом и сервером и перехватывает всю информацию между ними. Для клиента злоумышленник выглядит как банк, а для банка – как клиент. При этом циркулирующую информацию злоумышленник может не только читать, но и модифицировать.
Для защиты от этой угрозы был придуман в т.ч. и протокол SSL, который не только шифрует соединение между сторонами и контролирует целостность передаваемой информации, но и проверяет их подлинность с помощью сертификатов. До недавнего времени считалось, что SSL не подвержен атакам «человек посередине», но недавно по этой уверенности был нанесен удар; причем не один раз.
Начну с того, что в начале 2009-го года исследователь по имени Мокси Марлинспайк продемонстрировал утилиту SSLstrip, назначение которой было перехватывать SSL-соединения между пользователем и сервером. Идея данной атаки проста. Очень часто прежде чем инициировать SSL-соединение пользователь заходит на специальную страничку на Web-сервере, на которой вводит свои идентификационные параметры и нажимает кнопку «Войти». Суть в том, что пользователь заходит на эту страницу по обычному протоколу HTTP, а не HTTPS. SSLstrip просто перехватывает http-соединения пользователя и затем, выдавая себя за него, общается с сервером уже по протоколу HTTPS. Как показывает статистика, рядовые пользователи Интернет не очень-то обращают внимание, «горит» ли у них иконка замка в правом нижнем углу браузера (хотя она тоже может подменяться) и используется ли в адресной строке «https» вместо «http».
Противоположная по реализации атака была продемонстрирована еще в 2007-году Робертом Грэмом, который назвал ее SideJacking. Исследователь обратил внимание на то, что с целью экономии вычислительных ресурсов (а SSL требует немало мощностей для работы с открытыми ключами) на многих Интернет-сайтах портал для безопасного входа использует протокол HTTPS, а вот дальше сеанс осуществляется в открытую, без какого-либо шифрования. В качестве защитной меры используется идентификатор сессии (session ID). Это случайно генерируемая строка передается от сервера к клиенту либо через cookie, либо приписывается к URL. Именно этот идентификатор и интересует злоумышленника. Если удается его перехватить с помощью обычного сниффера, то дальше от имени пользователя можно выполнять почти все что угодно. К счастью банки очень редко используют такой механизм, в отличие от многих других Интернет-сервисов, таких как Gmail, Facebook, MySpace, «Одноклассники» и т.п.
Но все это не совсем атаки на SSL и внимательное отношение к тому, как вы подключаетесь к Интернет-банку, должно предотвратить вам нанесение ущерба. А вот дальше мы поговорим о еще двух возможностях снижения защищенности транзакций, защищенных SSL. Об одной из них стало известно в ноябре прошлого года, когда два исследователя из компании PhoneFactor опубликовали информацию о критической уязвимости в протоколе SSL/TLS (без изменения самого протокола устранить эту уязвимость невозможно), которая позволяет злоумышленникам вклиниться и добавлять свои данные в SSL/TLS-сессию, что в свою очередь дает им возможность выполнять нужные действия на удаленном сервере. В отношении данной атаки мнения экспертов разделились – одни считают, что режим, в котором возможно использование данной уязвимости (речь идет об аутентификации клиента) на практике почти не встречается, т.к. многие приложения (те же Интернет-банки) ограничиваются аутентификацией только серверной стороны. Сами же исследователи данной уязвимости считают, что лиха беда начало и возможность вклинивания в SSL/TLS-поток может привести к очень печальным последствиям.
Уже упомянутый ранее Мокси Марлинспайк нашел еще одну уязвимость, позволяющую вклиниться в SSL-сессию путем предоставления фальшивого сертификата, который многие современные приложения будут воспринимать, как настоящий. Не вдаваясь в детали скажу, что многие удостоверяющие центры, не совсем корректно автоматизировали процесс принятия запросов на регистрацию сертификатов. Проблема в том, что если вы владеете доменом iamhacker.ru и при этом пошлете запрос центру сертификации, в котором имя вашего домена записано следующим образом unicredit.ru\0.iamhacker.ru, то при проверке все, что находится перед префиксом «\0.» будет проигнорировано и ваш сертификат будет удостоверен. А вот при проверке сертификатов различными приложениями этот префикс будет учитываться. Иными словами, для проверяемого приложения домены «unicredit.ru» и «unicredit.ru\0.iamhacker.ru» будут идентичны. Из этого следует уже понятный вывод – любой запрос к серверу unicredit.ru может быть перенаправлен на сайт iamhacker.ru и при этом приложения не смогут обнаружить вторжение в SSL\TLS-сессию, что позволить злоумышленнику получить доступ к передаваемой в рамках транзакции информации.
Другой исследователь Джекоб Аппелбаум существенно улучшил атаку Марлинспайка и показал, как создать универсальный фальшивый сертификат, независимо от домена, который хотят атаковать злоумышленники. Один и тот же сертификат может быть использован для атак на любой Интернет-банк и иной Интернет-сервис, использующий протокол SSL. Тесты показали, что многие браузеры уязвимы к этой уязвимости и не выдают предупреждения об использовании фальшивого сертификата, если их не обновить.
Что показывают все перечисленный мной атаки и можно ли от них защититься? Безусловно. Достаточно только проверять сертификаты каждого узла, с которым вы общаетесь; как минимум с теми, которым вы доверяете свою конфиденциальную информацию и финансовые средства. Но вот многие ли это делают? Мы привыкли и ждем, что взаимодействие с Интернет-банком будет полностью автоматизированным, а банки заверяют нас, что оно еще и абсолютно надежно. В итоге у рядовых пользователей возникает чувство ложной защищенности, которое никто не стремится развенчать.
PS. Домен unicredit.ru использован только в качестве примера.