Миф 88. Сертификату Интернет-банка в браузере можно доверять

Форум Сообщества Практиков Конкурентной разведки (СПКР)

Конкурентная разведка, Бизнес-разведка, Корпоративная разведка,
Деловая разведка по открытым источникам в бизнесе.
Работаем строго в рамках закона.

Дезинформация и активные мероприятия в бизнесе
Форум Сообщества Практиков Конкурентной разведки (СПКР) »   Безопасность рабочего места »   Миф 88. Сертификату Интернет-банка в браузере можно доверять
RSS

Миф 88. Сертификату Интернет-банка в браузере можно доверять

<<Назад  Вперед>>Страницы: 1 2 3 4
Печать
 
Vinni
Администратор

Всего сообщений: 2710
Рейтинг пользователя: 22


Ссылка


Дата регистрации на форуме:
5 июня 2009
_ttp://bankir.ru/publication/article/6043093

[q]

...
В теории это действительно так. Схема достаточно проста. Чтобы удостоверить подлинность того или иного сайта они предоставляют так называемые сертификаты открытых ключей, которые идентичны паспортам обычных граждан. Но чтобы мы доверяли этим «паспортам», мы должны быть уверены, что они выданы именно тем организациям или людям, чьи имена записаны в сертификате. Эту уверенность нам гарантируют специальные корневые центры сертификации, которые принадлежат таким компаниям как 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 и т.д.). Браузер пользователя будет доверять такому сертификату и для клиента банка пользование подставным сайтом останется незамеченным.
...
[/q]



Интересное обсуждение темы есть также на _ttp://arkanoid.livejournal.com/311434.html

[q]

...
Проблема с архитектурой: отсутствует разделение зон доверия. Все верят всем. То есть, при существующей схеме, количество организаций, способных продделывать ЛЮБОЙ (а в этом и есть фатальная уязвимость, можешь построить "цепочку доверия" до известного корневого сертификата — тебя не ограничивает НИЧТО) сертификат не поддается никакому учету и растет экспоненциально. Я не буду вдаваться в подробности возможных технических уязвимостей (короткие ключи, слабые хэш-функции), уязвимости организационные на настоящий момент гораздо опаснее. Ford Motors, Yandex, NSA или безвестный аллахакбар-телеком из Эмиратов, которому посчастливилось получить сертификат промежуточного удостоверяющего центра могут подделать любой сайт в Интернете. И все это при том, что в рамках технологии x509v3 ввести разделение зон доверия (этот подписывай только в своем домене, этот — только в своей стране и т д) можно было на раз-два. Но никому же не хотелось морочиться..

Проблема с реализацией: естественно, что при таком бардаке, что бы там себе ни думал Витус, гораздо эффективнее модель доверия по схеме PGP — получил публичный ключ — сохрани, запомни, присвой ему статус доверия согласно личным причинам доверять или не доверять. Как проект monkeysphere рекомендует, например. Повторюсь, опять же, стотысячный раз: пользователю абсолютно плевать, принадлежит ли домен "odnoglazniki.ru" ЗАО "Одноглазники". Ему важно подтверждение того, что сайт на который он зашел утром и сайт, на который он зашел вечером — один и тот же. Но не тут-то было. Доблестные авторы браузеров сделали ВСЕ, чтобы сообщения об ошибках были максимально бессмысленны, пугающи, не позволяли реально оценивать степень риска и соответственно, игнорировались пользователями тотально.

Кстати, насчет аллахакбар-телекомов. Есть такой Etisalat в Эмиратах. Вот они дали джазу отлично: подключенным к ним владельцам Blackberry под видом апдейта прошивки подсунули троян, который крысит переписку, да еще и чудовищно сажает батарейку при этом. У этого Этисалата тоже есть сертификат удостоверяющего центра. EFF требует у Веризона, который подписал им этот сертификат, отозвать его. Веризон даже до ответа не снизошел. Выкорчевать гнилое дерево Verizon/Cybertrust при отсутствии официальной реакции, как, НЕСОМНЕННО, нужно было бы сделать в течении максимум месяца, пороху у Mozilla, например, явно не хватит, а остальные и не заморочатся.
...
[/q]
Vinni
Администратор

Всего сообщений: 2710
Рейтинг пользователя: 22


Ссылка


Дата регистрации на форуме:
5 июня 2009
продолжение темы - _ttp://habrahabr.ru/blogs/infosecurity/116084/

[q]

Сначала немного жёлтого:

Удостоверяющий центр Comodo Internet Security (их корневой сертификат объявлен заслуживающим доверия большинством производителей браузеров) подписало следующие сертификаты для неизвестных мошенников:

* mail.google.com, www.google.com
* login.yahoo.com (3шт)
* login.skype.com
* addons.mozilla.org
* login.live.com

Если мошенник предъявит этот сертификат, то он будет принят как правильный браузерами. Другими словами, не будет ни малейшего метода определить, что сайт поддельный.

Теперь подробнее. Эти сертификаты были выпущены, после чего началась подковёрная буча, производители браузеров (как минимум хром и файрфокс) внесли их в black list (вкомпиленный в код). Для firefox'а это произошло 17ого марта 2011 года, все версии, вышедшие до этого момента будут доверять этим сертификатам (я хотел было написать «подвержены уязвимости», но проблема в том, что это не уязвимость, это распиз… ство Comodo, которому почему-то все вынужены доверять). В теории, должна осуществляться проверка на то, не входит ли сертификат в список отзыва (его туда внесли), однако, на практике, если доступ к этому списку ограничен, то браузеры не выдают внятных предупреждений и доверяют сертификату.

Ссылки:

1) Пресс-релиз comodo: www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html
2) Secity Advisory от MS: www.microsoft.com/technet/security/advisory/2524375.mspx
3) Детективная история о том, как обнаружили «странное» в патчах в firefox'е до офицального обнародования результатов беспечности Comodo: blog.torproject.org/blog/detecting-certificate-authority-compromises-and-web-browser-collusion
4) О политической составляющей произошедшего: avva.livejournal.com/2321707.html
[/q]
Vinni
Администратор

Всего сообщений: 2710
Рейтинг пользователя: 22


Ссылка


Дата регистрации на форуме:
5 июня 2009
Кстати, последнее обновление FF3 включает в себя дополнение списка отозванных сертификатов с учетом этого инцидента

А мелкомягкие выпустили обновление (запускайте Windows Update :wink: ) - _ttp://support.microsoft.com/kb/2524375

Vinni
Администратор

Всего сообщений: 2710
Рейтинг пользователя: 22


Ссылка


Дата регистрации на форуме:
5 июня 2009
детали инцидента - _ttp://www.anti-malware.ru/news/2011-03-24/3846

[q]

Успешная атака против одного из партнеров компании COMODO позволила неизвестным взломщикам получить легитимные цифровые сертификаты для ряда крупнейших сетевых ресурсов - Google и Gmail, Microsoft, Skype, Yahoo. Руководитель известного поставщика средств и систем безопасности заявил, что за нападением стояло враждебное иностранное государство.

У COMODO есть подразделение UserTrust, которое занимается оформлением цифровых удостоверений для веб-сайтов; с помощью этих сертификатов определяется подлинность ресурсов, на имя которых они выданы. Сообщается, что хакеры смогли завладеть аутентификационными сведениями некоторой восточноевропейской компании, которая состоит в партнерских отношениях с COMODO - что, собственно, и позволило им сгенерировать нужные удостоверения. Напомним, что цифровые сертификаты могут быть полезны для фишеров: они придают кажущуюся легитимность вредоносным копиям известных Интернет-ресурсов.

Глава компании Мели Абдулла-оглы выразил уверенность в том, что атака обеспечивалась ресурсами некоторого враждебного государства и была "политически мотивированной". При этом, по его словам, отдельные признаки позволяют предполагать, что нападение было произведено с территории Ирана. Аналогичная точка зрения была изложена и в корпоративном блоге COMODO, где заявляется, что IP-адреса, с которых действовали взломщики, были приписаны к одному из иранских поставщиков услуг Интернета.

"Обычный киберпреступник предпринял бы атаку методом грубой силы, однако в данном случае образ действий был иным", - отметил г-н Абдулла-оглы. - "Это была тщательно скоординированная, можно даже сказать - хирургически точная операция; нападавшие четко знали, какие задачи им нужно выполнить и в какой срок".

В информационном бюллетене Microsoft, посвященном этому инциденту, говорится, что злоумышленники получили девять сертификатов: три для адреса login.yahoo.com и по одному для login.live.com, mail.google.com, www.google.com, login.skype.com, addons.mozilla.org и Global Trustee. Происшествие уже вынудило производителей популярных Интернет-обозревателей обновить свои программные решения: Chrome и Firefox получили исправления еще несколько дней назад, а патчи от Microsoft подоспели лишь вчера. Впрочем, обновление из Редмонда оказалось более масштабным: лже-сертификаты были внесены в черный список всех поддерживаемых на данный момент операционных систем Windows.

Computerworld

[/q]
Vinni
Администратор

Всего сообщений: 2710
Рейтинг пользователя: 22


Ссылка


Дата регистрации на форуме:
5 июня 2009
а вот что делает Гугл для защиты от атак с использованием фальшивых сертификатов - _ttp://googleonlinesecurity.blogspot.com/2011/04/improving-ssl-certificate-security.html

[q]

The first is the Google Certificate Catalog. Google’s web crawlers scan the web on a regular basis in order to provide our search and other services. In the process, we also keep a record of all the SSL certificates we see. The Google Certificate Catalog is a database of all of those certificates, published in DNS. So, for example, if you wanted to see what we think of https://www.google.com/’s certificate, you could do this:

$ openssl s_client -connect www.google.com:443 < /dev/null | openssl x509 -outform DER | openssl sha1
depth=1 /C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
verify error:num=20:unable to get local issuer certificate
verify return:0
DONE
405062e5befde4af97e9382af16cc87c8fb7c4e2
$ dig +short 405062e5befde4af97e9382af16cc87c8fb7c4e2.certs.googlednstest.com TXT
"14867 15062 74"

In other words: take the SHA-1 hash of the certificate, represent it as a hexadecimal number, then look up a TXT record with that name in the certs.googlednstest.com domain. What you get back is a set of three numbers. The first number is the day that Google’s crawlers first saw that certificate, the second is the most recent day, and the third is the number of days we saw it in between.

In order for the hash of a certificate to appear in our database, it must satisfy some criteria:

It must be correctly signed (either by a CA or self-signed).
It must have the correct domain name — that is, one that matches the one we used to retrieve the certificate.

The basic idea is that if a certificate doesn’t appear in our database, despite being correctly signed by a well-known CA and having a matching domain name, then there may be something suspicious about that certificate. This endeavor owes much to the excellent Perspectives project, but it is a somewhat different approach.

Accessing the data manually is rather difficult and painful, so we’re thinking about how to add opt-in support to the Chrome browser. We hope other browsers will in time consider acting similarly.

The second initiative to discuss is the DANE Working Group at the IETF. DANE stands for DNS-based Authentication of Named Entities. In short, the idea is to allow domain operators to publish information about SSL certificates used on their hosts. It should be possible, using DANE DNS records, to specify particular certificates which are valid, or CAs that are allowed to sign certificates for those hosts. So, once more, if a certificate is seen that isn’t consistent with the DANE records, it should be treated with suspicion. Related to the DANE effort is the individually contributed CAA record, which predates the DANE WG and provides similar functionality.

One could rightly point out that both of these efforts rely on DNS, which is not secure. Luckily we’ve been working on that problem for even longer than this one, and a reasonable answer is DNSSEC, which enables publishing DNS records that are cryptographically protected against forgery and modification.

It will be some time before DNSSEC is deployed widely enough for DANE to be broadly useful, since DANE requires every domain to be able to use DNSSEC. However, work is on the way to use DNSSEC for the Certificate Catalog well before the entire DNSSEC infrastructure is ready. If we publish a key for the domain in which we publish the catalog, clients can simply incorporate this key as an interim measure until DNSSEC is properly deployed.

[/q]
Vinni
Администратор

Всего сообщений: 2710
Рейтинг пользователя: 22


Ссылка


Дата регистрации на форуме:
5 июня 2009
еще инцидент с фальшивыми сертификатами -_ttp://isc.sans.edu/diary.html?n&storyid=11479
обратите внимание, что сделали сертификат для Гугл.
Мелкомягкие в ответ выпустили обновление, убирающее из списка доверенных CA их корневой сертификат (для XP обновления не сделали ...) - _ttp://www.microsoft.com/technet/security/advisory/2607712.mspx
Vinni
Администратор

Всего сообщений: 2710
Рейтинг пользователя: 22


Ссылка


Дата регистрации на форуме:
5 июня 2009
Развитие инцидента - _ttp://isc.sans.edu/diary.html?n&storyid=11500
обратите внимание на подделку сертификата для tor :goodbuy:
Vinni
Администратор

Всего сообщений: 2710
Рейтинг пользователя: 22


Ссылка


Дата регистрации на форуме:
5 июня 2009
сходите еще раз по ссылке в посте выше - там обновление вышло.
Все оказалось гораздо хуже и сейчас эту датскую лавочку закрывают

Плюс отчет аудитора вышел - _ttps://isc.sans.edu/diary.html?n&storyid=11512 :reful:
Vinni
Администратор

Всего сообщений: 2710
Рейтинг пользователя: 22


Ссылка


Дата регистрации на форуме:
5 июня 2009
публикации на эту тему на русском
_ttp://www.securitylab.ru/news/407085.php
_ttp://www.securitylab.ru/news/407065.php
_ttp://www.securitylab.ru/news/407053.php

UPDATE
еще ссылка на введение в проблему - _ttp://www.anti-malware.ru/news/2011-09-06/4585
Vinni
Администратор

Всего сообщений: 2710
Рейтинг пользователя: 22


Ссылка


Дата регистрации на форуме:
5 июня 2009
а вот альтернативный подход - _ttp://habrahabr.ru/blogs/infosecurity/127795/
<<Назад  Вперед>>Страницы: 1 2 3 4
Печать
Форум Сообщества Практиков Конкурентной разведки (СПКР) »   Безопасность рабочего места »   Миф 88. Сертификату Интернет-банка в браузере можно доверять
RSS

Последние RSS
Open Source Intelligence (OSINT) Tools and Resources Handbook
Top tips on gathering information about companies by using free online sources
Новое на блоге HRразведка
Безопасность данных в MS Access
Слово как улика
20 Recon and Intel Gathering Tools used by InfoSec Professionals
What’s Changed?
10 альтернативных поисковиков
Ситуационный центр главы Республики Коми
Развёртывание ситуационных центров на базе технологии Avalanche
Как принимать сложные решения. Советы бывшего оперативника ЦРУ.
Открытая информация о "Новичке" из сети интернет.
Ген. директор "ОЗХО" Ахмет Узюмдж о "Новичке" и хим. атаке в Сирии
Онлайн-сервисы для Twitter
Коллекция для Twitter
Приложение Opera VPN закрывается
О работе разведки
Deep web и 11 поисковиков по нему
Об изначальной "лживости" любых документов
Обновление на блоге HRазведка

Самые активные 20 тем RSS
Стандартные источники информации в СайтСпутнике
Слово как улика
Open Source Intelligence (OSINT) Tools and Resources Handbook
Top tips on gathering information about companies by using free online sources
Новое на блоге HRразведка
WebSite Watcher
Безопасность данных в MS Access