информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Атака на InternetПортрет посетителяSpanning Tree Protocol: недокументированное применение
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Ростелеком заподозрили в попытке... 
 Линуксовый ботнет, распространяющийся... 
 Конец поддержки Internet Explorer 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / theory
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
В своём первом мессе я как раз о двух разных УЦ говорил,... 13.04.06 16:07  Число просмотров: 2618
Автор: sattva Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> > А вот тут облом :). Root CA не выдаст два сертификата
> на
> > одно имя разным людям.
>
> Если они действуют сообща, то конечно. Вопрос: ты уверен,
> что они обмениваются базами подписей?

В своём первом мессе я как раз о двух разных УЦ говорил, что, видимо, не заметил первый отвечающий.

Любопытства ради сформировал CSR для gmail.com и передал его в CACert. Теперь имею SSL-сертификат X.509 для популярной почтовой службы. С кем поделиться? ;) Для атаки на Firefox/Mozilla не подойдёт (CACert в хранилище браузера отсутствует), но против Эксплорера -- вполне.
<theory>
Спуфинг SSL-защищённых серверов 12.04.06 13:40  
Автор: sattva Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Господа, верно ли я себе представляю возможный сценарий атаки на SSL-защищённый веб-сервис для некоторого пользователя (это может быть фишинг-атака или нечто подобное)?

1. Противник взламывает DNS-сервер интернет-провайдера целевого пользователя или иной DNS, близко расположенный к пользователю и кэширующий его запросы.
2. Для данного доменного имени он заменяет IP-адрес легитимного сервера IP-адресом подконтрольного ему сервера.
3. Поскольку легитимный сервер использует SSL-сертификат известного удостоверяющего центра, оппонент заказывает у другого УЦ (чей корневой сертификат имеется в хранилище браузера пользователя) сертификат для того же доменного имени (допустим, этими УЦ являются VeriSign и Thawte).
4. Оппонент устанавливает "поддельный" сертификат на свой сервер.
5. При обращении к легитимному серверу пользователь будет перенаправлен (благодаря подмене в DNS-таблице) на подставной сервер, подконтрольный противнику. Поскольку сертификат этого сервера также заверен ключом доверенного УЦ, пользователь не заметит атаки и будет считать, что соединение надёжно.

Единственная проблема, которую я вижу (не считая взлома DNS ;)), это если УЦ поддерживает базу своих пользователей и принадлежащих им доменов и для логина в систему и отправки CSR требует логин/пароль, то такой сценарий усложняется.

Чего ещё на ваш взгляд в супе не хватает?
А вот тут облом :). Root CA не выдаст два сертификата на... 12.04.06 16:37  
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
<"чистая" ссылка>
> Господа, верно ли я себе представляю возможный сценарий
> атаки на SSL-защищённый веб-сервис для некоторого
> пользователя (это может быть фишинг-атака или нечто
> подобное)?
>
> 1. Противник взламывает DNS-сервер интернет-провайдера
> целевого пользователя или иной DNS, близко расположенный к
> пользователю и кэширующий его запросы.
> 2. Для данного доменного имени он заменяет IP-адрес
> легитимного сервера IP-адресом подконтрольного ему сервера.
> 3. Поскольку легитимный сервер использует SSL-сертификат
> известного удостоверяющего центра, оппонент заказывает у
> другого УЦ (чей корневой сертификат имеется в хранилище
> браузера пользователя) сертификат для того же доменного
> имени (допустим, этими УЦ являются VeriSign и Thawte).

А вот тут облом :). Root CA не выдаст два сертификата на одно имя разным людям.

> 4. Оппонент устанавливает "поддельный" сертификат на свой
> сервер.
> 5. При обращении к легитимному серверу пользователь будет
> перенаправлен (благодаря подмене в DNS-таблице) на
> подставной сервер, подконтрольный противнику. Поскольку
> сертификат этого сервера также заверен ключом доверенного
> УЦ, пользователь не заметит атаки и будет считать, что
> соединение надёжно.
>
> Единственная проблема, которую я вижу (не считая взлома DNS
> ;)), это если УЦ поддерживает базу своих пользователей и
> принадлежащих им доменов и для логина в систему и отправки
> CSR требует логин/пароль, то такой сценарий усложняется.

именно так и есть. только там нету по-моему никакого логина/пароля.

> Чего ещё на ваш взгляд в супе не хватает?
А два разных рута? 12.04.06 20:03  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> А вот тут облом :). Root CA не выдаст два сертификата на
> одно имя разным людям.

Если они действуют сообща, то конечно. Вопрос: ты уверен, что они обмениваются базами подписей?
В своём первом мессе я как раз о двух разных УЦ говорил,... 13.04.06 16:07  
Автор: sattva Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> > А вот тут облом :). Root CA не выдаст два сертификата
> на
> > одно имя разным людям.
>
> Если они действуют сообща, то конечно. Вопрос: ты уверен,
> что они обмениваются базами подписей?

В своём первом мессе я как раз о двух разных УЦ говорил, что, видимо, не заметил первый отвечающий.

Любопытства ради сформировал CSR для gmail.com и передал его в CACert. Теперь имею SSL-сертификат X.509 для популярной почтовой службы. С кем поделиться? ;) Для атаки на Firefox/Mozilla не подойдёт (CACert в хранилище браузера отсутствует), но против Эксплорера -- вполне.
Да, теперь понял идею. Это ужас. Единственное что я не нашел... 14.04.06 18:09  
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
<"чистая" ссылка>
> В своём первом мессе я как раз о двух разных УЦ говорил,
> что, видимо, не заметил первый отвечающий.
>

Да, теперь понял идею. Это ужас. Единственное что я не нашел CACert в списке trusted publishers IE. Ты уверен что он там есть?

> Любопытства ради сформировал CSR для gmail.com и передал
> его в CACert. Теперь имею SSL-сертификат X.509 для
> популярной почтовой службы. С кем поделиться? ;) Для атаки
> на Firefox/Mozilla не подойдёт (CACert в хранилище браузера
> отсутствует), но против Эксплорера -- вполне.
Действительно, облом. Но на итог вряд ли повлияет 14.04.06 22:11  
Автор: sattva Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Да, теперь понял идею. Это ужас. Единственное что я не
> нашел CACert в списке trusted publishers IE. Ты уверен что
> он там есть?

Проверил хранилище. Ты прав, нету CACert. Но всё же я уверен, что при желании найти из всего множества доверенных для эксплорера УЦ такой, который выдаёт "экспресс-сертификаты" (заверяет CSR без веттинга) можно. Нам не обязательно знать, какие доказательства владения требует большинство УЦ; нам нужно найти только одну точку сбоя.
Я понял, потому и возразил NKritsky 13.04.06 16:58  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> В своём первом мессе я как раз о двух разных УЦ говорил,
> что, видимо, не заметил первый отвечающий.

> Любопытства ради сформировал CSR для gmail.com и передал
> его в CACert. Теперь имею SSL-сертификат X.509 для

А вот это интересно. Все таки никакой синхронизации друг с другом они не производят и таким образом теряется вся идея сертификации.

> популярной почтовой службы. С кем поделиться? ;) Для атаки
> на Firefox/Mozilla не подойдёт (CACert в хранилище браузера
> отсутствует), но против Эксплорера -- вполне.

Если учесть сегмент рынка, занимаемый эксплорером, то даже если CACert - единственный, кто не синхронизируется (что вряд ли), то все равно весьма серьезная уязвимость
Если принять во внимание число корневых сертификатов, вшитых... 13.04.06 20:45  
Автор: sattva Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> > популярной почтовой службы. С кем поделиться? ;) Для
> атаки
> > на Firefox/Mozilla не подойдёт (CACert в хранилище
> браузера
> > отсутствует), но против Эксплорера -- вполне.
>
> Если учесть сегмент рынка, занимаемый эксплорером, то даже
> если CACert - единственный, кто не синхронизируется (что
> вряд ли), то все равно весьма серьезная уязвимость

Если принять во внимание число корневых сертификатов, вшитых в эксплорер, я вообще слабо себе представляю, как бы удостоверяющие центры сверяли друг с другом списки заверенных сертификатов. Видимо, логика PKI и действующих УЦ исходит из допущения, что раз уж установить SSL-сертификат на сервер может только администратор, то не стоит и беспокоиться.

В порядке лирического отступления хочу вспомнить случай, обсуждавшийся пару лет назад в списке рассылки шифрпанков, когда корневой сертификат доверенного для эксплорера какого-то малоизвестного УЦ был продан с молотка вместе с остальной собственностью этого УЦ после его банкротства. Название УЦ забыл, но это и не важно.

Конечно, я не оригинален. В последние годы не плевал в PKI только ленивый. :)
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2022 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach