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





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Да, теперь понял идею. Это ужас. Единственное что я не нашел... 14.04.06 18:09  Число просмотров: 2866
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
<"чистая" ссылка>
> В своём первом мессе я как раз о двух разных УЦ говорил,
> что, видимо, не заметил первый отвечающий.
>

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

> Любопытства ради сформировал 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-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach