100 Мифы и заблуждения информационной безопасности Лукацкий
| Вид материала | Документы |
- Аннотация, 418.67kb.
- Е. А. Свирский Рассматриваются вопросы работы курсов повышения квалификации по информационной, 67.93kb.
- Система менеджмента информационной безопасности, 205.89kb.
- Теоретические основы информационной безопасности автоматизированных систем, 26.65kb.
- Содержание курса. Урок, 902.96kb.
- Обеспечение информационной безопасности организации как метод антикризисного управления, 54.18kb.
- Мифы Древней Греции Мифы Древней Индии Мифы древних славян Мифы североамериканских, 33.93kb.
- «Комплексные системы информационной безопасности», 260.23kb.
- Вопросы по информационной безопасности, 268.68kb.
- Рекомендации по обеспечению информационной безопасности Заключение, 358.69kb.
Миф №87 «Ограничение на сумму платежа через Интернет спасает от незаконного снятия средств со счета»10.08.2010 13:46
Алексей Лукацкий - менеджер по развитию бизнеса Cisco Systems
Совсем недавно я пытался купить авиабилеты в Екатеринбург, чтобы прочитать там свой курс по моделированию угроз. Зайдя на сайт «Уральских авиалиний», я указал номера рейсов, их даты и ввел реквизиты своей карты Visa… Однако в оплате мне было отказано. Я стал разбираться и выяснил, что процессинг моего банка ограничил сумму платежа по карте через Интернет лимитом в 300 долларов. Билеты же при этом стоили около 350-380 долларов. Это один из распространенных механизмов защиты клиентов Интернет-банков от незаконного снятия средств со счет (хотя и им пользуются далеко не все банки, не желая ограничивать своих клиентов). Но достаточно ли его для борьбы с данной угрозой?
Оказывается только одного этого механизма для борьбы с мошенничеством уже недостаточно и вот почему. В октябре прошлого года был обнаружен новый троянец, получивший название ссылка скрыта (он же Bebloh), который атаковал клиентов нескольких немецких банков. Механизмы, заложенные в URLzone, раньше специалистам не встречались. Клиент Интернет-банка, зайдя в свою виртуальную сейфовую ячейку, начинал как обычно работать со своими счетами. В этот момент, спящий до поры до времени троянец, активизировался и начинал скрытно переводить деньги на подставные счета. Что в этом удивительного, спросите вы? Удивительно то, что, во-первых, URLzone по окончании своей работы демонстрировал пользователю неверное состояние баланса его счета, на лету подменяя финансовые показатели в выписке. Это позволяет скрыть на время факт кражи денег. За этот период злоумышленники успевали обналичить деньги и скрыться от правоохранительных органов.
Второй инновацией можно назвать интеллектуальную систему подбора суммы перевода. Если другие банковские троянцы пытаются украсть либо максимальную сумму на счете, либо фиксированную. А вот URLzone каждый раз подбирает сумму так, чтобы обойти систему борьбы с мошенничеством, установленную в банке. Также URLzone не полностью опустошал счет жертвы, а оставлял небольшую сумму, чтобы опять не возбудить интереса у банковской службы безопасности. При этом реквизиты подставных счетов, пороговые значения перевода и опустошения счета могут динамически меняться по команде из центра, расположенного на Украине. Данный троянец был направлен в первую очередь на европейские (преимущественно немецкие) банки, но не исключена его переквалификация и на другие страны. Тем более, что в состав данного троянца входит специальный модуль URLzone Builder, который и создает конфигурационный файл, в соответствии с которым и действует URLzone, в т.ч. и указать адрес любого банка.
Кстати, у URLzone есть и еще ряд функций, как стандартных (например, пересылка копий экрана), так и достаточно интересных. В частности, в URLzone реализован механизм обхода одноразовых TAN-кодов. Работает эта схема следующим образом – после ввода одноразового пароля и нажатия кнопки «Оплатить» троянец просто подменяет реквизиты перевода «на лету».
Как видим обычный контроль пороговых значений переводимых средств не решает проблему незаконного снятия денег со счета. Нужна комбинация подходов. Например, в ряде банков совершить перевод на внешний счет невозможно, если этот счет предварительно не введен в соответствующий справочник. Это простая, но эффективная (при правильной реализации) мера борьбы с несанкционированными переводами. Но гораздо более эффективным является внедрение специализированных решений по борьбе с мошенничеством, которые, опираясь на профиль поведения клиента, контролируют все его транзакции. К числу компаний, выпускающих такие решения, относятся ссылка скрыта, Cydelity (сейчас часть ссылка скрыта), Bharosa (сейчас часть ссылка скрыта), Cyota (сейчас часть ссылка скрыта), Business Signatures (сейчас часть ссылка скрыта) и т.д
Миф №88 «Сертификату Интернет-банка в браузере можно доверять»26.08.2010 00:31
В рамках рубрики "Клуб экспертов" мы продолжаем публикацию книги А.В.Лукацкого ссылка скрыта
Алексей Лукацкий - менеджер по развитию бизнеса Cisco Systems
На многих сайтах Интернет-банков есть такая рекомендация – убедитесь, что при подключении к своему счету браузер использует защищенное соединение HTTPS, что может быть проверено либо через адресную строку, либо через иконку справа внизу браузера. Некоторые банки даже утверждают, что наличие этих признаков «обеспечивает надежный, защищенный и доверенный доступ» к счету.
Рис. 1. https указывает на защищенное соединение
Рис. 2. Иконка замка указывает на защищенное соединение
Но так ли это и насколько сертификату, отображаемому при нажатии на иконку замка, можно доверять?
В теории это действительно так. Схема достаточно проста. Чтобы удостоверить подлинность того или иного сайта они предоставляют так называемые сертификаты открытых ключей, которые идентичны паспортам обычных граждан. Но чтобы мы доверяли этим «паспортам», мы должны быть уверены, что они выданы именно тем организациям или людям, чьи имена записаны в сертификате. Эту уверенность нам гарантируют специальные корневые центры сертификации, которые принадлежат таким компаниям как VeriSign, Thawte, RapidSSL и т.п. Именно они и подтверждают, что указанные в сертификате данные принадлежат реальным лицам, а не мошенникам (при этом сертификаты данных корневых центров уже включены в состав операционной системы или браузера и им доверяют по умолчанию). Сразу замечу, что ничего не стоит обмануть эти компании. Когда-то я выписывал в Thawte сертификат на свое имя и никто, по сути, не проверял, существую ли я, действительно ли моя фамилия «Лукацкий» и работаю ли я указанной при регистрации компании. Поэтому мне ничего не стоило запросить сертификат на любое имя. А заплатив немного, я бы мог запросить сертификат и на имя почти любого юридического лица.
Но допустим, корневые центры сертификации проводят полную проверку и выдают сертификаты только тем компаниям, чьи имена проверены. Но допустим, мошенники, желающие обокрасть клиентов банка ЗАО «Банк Имярек», зарегистрировали новое юрлицо ООО «Банк Имярек» или ПБОЮЛ «Банк Имярек», и получили на него свой сертификат. Имена организация похожи до степени смешения, как и их сертификаты. Дальше злоумышленникам достаточно просто заставить пользователя зайти на подставной сайт, на котором и будет размещен фальшивый сертификат. Т.к. 99,99% пользователей Интернет не присуща привычка проверять сертификаты посещаемых ими сайтов, то мошенничество достигнет своей цели. Хотя с точки зрения теории криптографии схема будет по-прежнему идеальной. Но вот на практике…
Другой пример. До недавнего времени в Интернете могли существовать домены, состоящие только из латинских символов и арабских цифр. Но недавно была принята система IDN (Internationalized Domain Names), т.е. система доменных имен, содержащих символы национальных алфавитов. Например, если раньше в Рунете мог существовать только один сайт компании Coca-Cola – www.cocacola.ru, то со временем появился сайт cocacola.su, содержащий негативную информацию о всем известной продукции. Теперь же появилась возможность зарегистрировать сайт по адресу «кокакола.рф». Что мешает злоумышленникам при наличии домена, например, unicredit.ru зарегистрировать домен «юникредит.рф»? Ведь существует же домен unicredit.su и по этому адресу вас встречает якобы банковский форум (на котором почему-то всего 1 сообщение). И если в сертификате мошеннического Интернет-банка будет прописан не настоящий домен unicredit.ru, а подставной unicredit.su или юникредит.рф, то кто из пользователей заметит разницу? А если и заметит, то многие ли заподозрят в этом подвох? «Может быть банк Юникредит просто следует тенденциям регистрировать свою торговую марку в разных доменах», - подумают они. Хорошо, что сегодня в России нельзя зарегистрировать (по крайней мере официально) домены, содержащие одновременно символы из разных алфавитов. Иначе мы столкнулись бы с ворохом ранее невиданных проблем. Например, кто бы мог сказать, чем отличаются домены «unicredit.ru» и «uniсredit.ru»? Ничем, скажет большинство и будет неправо. В первом случае в названии используется английская буква «c», а во втором русская – «с».
Но и на этом не заканчиваются проблемы. Вся схема «доверия» построена на том, что сертификаты подписаны и злоумышленники не могут создать второй сертификат с той же цифровой подписью, но фальшивым содержанием. Но и это было только в теории. В конце 2008-го года на 25-м Конгрессе «хакерской» группы Chaos Communication Club была продемонстрирована практическая возможность создания фальшивого сертификата, который позволяет выдать себя за любой сайт в Интернет, использующий протокол HTTPS, в т.ч. и Интернет-банки.
Суть проблемы заключалась в найденной уязвимости в алгоритме MD5, который использовался для проверки подлинности сертификатов. Эта, считавшаяся чисто теоретической, проблема позволила исследователям создать фальшивый центр сертификатов и подписать с его помощью любое количество фальшивых сертификатов, которые, несмотря на это, будут считаться доверенными для клиентов. В случае с Интернет-банком злоумышленники могут заставить клиента перейти на подставной сайт (либо путем установки троянца, либо путем модификации файла windows\system32\driver\etc), который предоставит пользователю фальшивый сертификат, удостоверенный фальшивым центром сертификации, который в свою очередь подтвержден настоящим корневым центром (в числе уязвимых к такой атаке удостоверяющих центром относятся Thawte, VeriSign, RSA Security, RapidSSL, FreeSSL и т.д.). Браузер пользователя будет доверять такому сертификату и для клиента банка пользование подставным сайтом останется незамеченным.
Рис. 3. Фрагмент сертификата Интернет-банка Юникредитбанка
Есть и еще один сценарий. С помощью OpenSSL можно создать сертификат «корневого» доверенного центра от имени которого затем и будут злоумышленниками создаваться подставные сертификаты. Такой сертификат доверенного центра может быть загружен на компьютер пользователя с помощью вредоносной программы, и браузер будет доверять ему по умолчанию.
Что можно сделать в такой ситуации? Клиенту банка практически ничего. Проблема не сертификатах, как таковых, не в протоколе SSL, и не в криптографии. Речь идет об организационных процедурах. Необходимо или удалять все сертификаты, использующие MD5 (оставив подписанные SHA1), или серьезно ограничить список корневых центров сертификации, которым вы доверяете (помимо классических рекомендаций установки антивируса, регулярного обновления ПК и т.п.), а это практически нереально. Основной набор рекомендаций касается удостоверяющих центров и остается только надеяться, что они к ним прислушаются.