Кот Муций (cat_mucius) wrote,
Кот Муций
cat_mucius

Categories:
  • Music:
Что-то никто, кроме yigal-s, над вопросом про сертификаты думать не захотел. :-)
Ладно, просто так расскажу. Интересны они вот чем: один из них настоящий. Другой - поддельный. А подпись у них одинакова.

Краткая напоминалка, как это всё работает: сертификат – это электронный документ, удостоверящий в сети кого-то или что-то: вебсайт, компьютер, юзера, адрес мейла. Для того, чтобы этому документу кто-то доверял, надо, чтобы он был подписан каким-то гарантом, к которому доверие уже есть. Такими гарантами выступают фирмы вроде VeriSign и Comodo, которые этим и занимаются – продают сертификаты. Называют их CA (certification authorities).

Как работает электронная подпись? Берётся этот самый документ и прогоняется через хэш-функцию. У хэш-функции же есть две особенности:
• Для каждого значения на входе она должна выдать уникальное значение на выходе. В идеале, не должно быть двух разных наборов данных, для которых функция выдаст одинаковый хэш. Ситуация, когда такое всё же происходит, называется collision и говорит о том, что функция плоха.
• Из хэша на выходе не должно быть возможно узнать, что было скормлено функции на входе.
Авторы схемы защиты вируса Gauss использовали вторую особенность – здесь же нас интересует первая.

Итак, берётся сертификат и вычисляется его хэш. После чего CA, что подписывает сертификат (скажем, VeriSign), шифрует его своим секретным ключом. Результат шифрования – это и есть электронная подпись, которая прилагается к сертификату. Тот же, кто хочет подпись проверить (скажем, браузер) делает вот что: а.) в свою очередь вычисляет хэш по тем же данным, б.) расшифровывает подпись открытым ключом того, кто её зашифровал и с.) сравнивает результат. Если в сертификате или подписи был изменён хотя бы один бит, то сравнение проваливается и значит, подпись поддельная и доверять ей нельзя.

Нетрудно заметить, что если у двух сертификатов будет одинаковый хэш, то и результат шифрования тайным ключом удостоверителя выйдет одинаков. Если я могу взять сертификат, удостоверяющий сайт https://mail.google.com, и составить свой с таким же именем и таким же хэшем, то мне совершенно необязательно знать секретный ключ фирмы VeriSign, подписавшей сертификат Гугля – я могу просто скопировать подпись из сертификата Гугля и пришпандорить к своему. После чего построить липовый сайт, выдающий себя за https://mail.google.com и перехватывать пароли. Именно поэтому требования не повторяющихся значений на выходе хэш-функции настолько важно: уникальный хэш = уникальная подпись.


Амбула:

Так вот, в 2008-м группа из семи исследователей именно этого и добилась – сумела сгенерировать пару сертификатов так, чтобы хэш у них вышел одинаков. После чего подсунула один из них на подпись к одному из CA – фирме Equifax / GeoTrust. Поскольку критериям CA сертификат вполне удолетворял (несмотря на указанное в нём имя сайта i.broke.the.internet.and.all.i.got.was.this.t-shirt.phreedom.org), то GeoTrust его автоматически подмахнула за малую мзду. После чего остался последний ход: подпись просто взяли и приставили ко второму сертификату, который GeoTrust не подписала бы ни в жисть. А не подписала бы потому, что второй был выписан не на какой-то там вебсайт, настоящий или липовый – а на дочерний CA, который автоматом наследует весь капитал доверия, которым располагает GeoTrust. То есть хозяева поддельного сертификата получили прекрасную возможность выписывать в свою очередь любые другие сертификаты, которым бы браузеры доверяли автоматически.

Выгорело дело, кстати, потому, что GeoTrust полагалась на хэш-функцию по нынешним временам слабую – MD5. Первую полноценную коллизию в MD5 нашли ещё в 2004-м, но от того, чтобы просто найти два каких-то куска информации с одинаковым хэшем и до того, чтобы подобрать таким образом два куска _нужной_ информации – дистанция огромного размера, и великолепная семёрка её преодолела. Всякие смачные детали, вроде вычислений на кластере из двухста игровых консолей, можете почитать здесь, а я поговорю о последствиях.


Что могло бы выйти:

Последствий особых не было, разве что все СA бросились срочно менять MD5 на более стойкий алгоритм – SHA1. Но не было лишь потому, что авторы работы, из социальной ответственности, постарались собственные результаты всячески обезвредить. Во-первых, отказались разгласить ключ, с помощью которого могли бы выписывать дочерние сертификаты. Во-вторых, свой липовый сертификат предусмотрительно создали дохлым с рожденья – со сроком жизни всего-то в август 2004-ого. И в третьих, просто не опубликовали некоторые секретные тонкости своей технологии.

Ну а если бы они решили пуститься во все тяжкие? У, тут последствия могли быть жирные. Корневым сертификатам Equifax / GeoTrust доверяют подавляющее большинство компьютеров в мире (и твой собственный, дорогой читатель – не веришь, запусти certmgr.msc и полюбуйся на список в "Trusted Root Certification Authorities"), они поставляются вместе с операционными системами и браузерами, такими, как Firefox. Это значит, что дочернему – липовому – CA они доверяли бы точно так же. А это открывает большие возможности:

• Можно выписать сертификат на абсолютно любой сайт – хоть на https://www.facebook.com/, хоть на https://www.paypal.com. После чего с помощью MitM-атаки или фишинга красть пароли, личную информацию, коммерческие секреты, просто деньги. Причём совершенно неважно, что Пайпалу сертификат выписал не GeoTrust, а вовсе даже VeriSign, и без всякого MD5.

• Можно подписывать какой-нибудь malware. Сегодня туча програм подписывается каким-нибудь CA, чтобы юзер не боялся запускать их на своей машине. Windows при попытке поставить програмку без подписи уже и предупреждение выкатывает... Так вот, берём любого троянского коня, любой spyware, и снабжаем его подписью – создано Microsoft. После чего хошь – ботнет строй, хошь – пароли кради, ну и бабло, опять же.

• Можно перехватывать шифрованные каналы IPsec / VPN, можно ловить пароли от копроративных WiFi-сеток.

• Можно тот же malware рассылать подписанными / шифрованными мэйлами, чтобы спаморезки пропускали и юзеры ловились, а то и проводить сложные мошеннические схемы с фальшивыми документами, но это скорее экзотика.

В общем, нехило оторваться можно. Причём в любую из этих ловушек не то что обычный юзер, но и админ-параноик вденется в полный рост. Что, кто-то помнит наизусть, какой CA выписал сертификат его банку?


Контрмеры:

Хорошо, допустим, какие-то атаки бы удались – но потом началось бы расследование и на свет божий выплыло бы существование липового CA. Насколько эффективно можно было бы свести возможность повторных атак на нет?

Вообще-то, не особенно. Основной способ борьбы с сертификатами, попавшими не в те руки, это “чёрные списки”, называемые CRL (certificate revocation list). Каждый CA публикует такой список, куда вносит сертификаты, которым призывает больше не доверять. В теории, браузеры или любые иные программы, желающие проверить сертификат, должны прочесть свежий CRL от того CA, что подписал сертификат и убедиться, что его серийного номера нет в списке.

То есть GeoTrust могли бы взять серийник нашего липового сертификата и забить его в свой список (вот он, кстати - http://crl.geotrust.com/crls/globalca1.crl).

Проблема в том, что способ этот очень ограничен:

1.) Как браузер вообще узнаёт, где искать CRL? Ответ: URL к нему публикуется прямо в том же сертификате, который браузер и хочет проверить. Бредово? В общем да: основано это на предположении, что подделать сертификат нельзя, и призвано для защиты от иных сценариев (утечка ассоциированного с сертификатом секретного ключа, в основном).

Ну а наш поддельный сертификат адреса CRL вообще не содержит, и привет. И ни один браузер по этому поводу не заверещит, потому как ситуация эта нормальна: нет требования, чтобы любой сертификат непременно содержал линк к CRL. И даже если бы такое требование было, обойти его было бы легко: достаточно поставить неработающий линк, или работающий, но на битый CRL, или даже вполне целый, с отменной подписью законнейшего CA, только ... устаревший. Браузеры не склонны портить user experience предупреждающими воплями лишь потому, что не удалось прочесть самый свежий CRL, да ещё и не первый в цепочке.

2.) Тем не менее, есть способы, которыми CRL может дойти до потенциальных жертв:
     a. Допустим, браузер открыл сайт, защищёный легальным сертификатом от того же Equifax, в ходе проверки скачал CRL и закэшировал его. Тогда, покамест CRL хранится в кэше, попытки подсунуть фальшак провалятся.
Проблема в том, что это чисто вероятностная штука.

     b. Иные механизмы, такие, как Windows Update. После того, как иранский хакер смог заполучить сертификаты к набору разных важный сайтов два года назад, этот способ и использовался: вместе с заплатками к операционке на компьютер спускался CRL c номерами забаненных сертификатов и сами эти сертификаты.
Проблема в том, что далеко не все компы получают регулярно обновления.

3.) Не все браузеры вообще удосуживаются проверять CRL, поскольку это замедляет загрузку страниц – нужно дополнительно побегать по линкам и проверить подписи.

4.) Наконец, есть сценарии, когда проверить CRL просто невозможно. Например, когда сертификат используется для защиты доступа в сетку WiFi. Как клиенту убедиться, что сертификат не отозван, когда у него и IP-адреса ещё даже нет?

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

Вот какая неприятность может произойти всего-то из того, что хэш-функция для двух input’ов выдала один output. :-)


Выводы:

1. Всякий, имеющий дело с сертификатами с MD5 – да отряхнёт их прах с рук своих.

2. Да и на SHA1 лучше не полагаться. Если его завтра вот так ломанут, это будет ОЙ! – потому как почти все сертификаты подписываются с SHA1RSA.

3. Сисадмин, помни, что иерархия доверия – вообще-то, необходимое зло, призванное решать проблему scalability, а не нечто прекрасное само по себе. Если есть возможность установить точечное доверие к конечному сертификату, а не полагаться на цепочку подписей – стоит это делать.

4. Доверять стопроцентно одной лишь технологии никогда не стоит. Защищать передачу юзерского пароля одним лишь SSL – плохая идея, лучше использовать дополнительную схему типа digest / NTLM / Kerberos, даже если обмен идёт по шифрованному каналу.

5. Нужен способ проверки CRL-ей и цепочек доверия сверху вниз, от корневого CA, а не наоборот. Логичный кандидат для этого, кстати, есть – DNSSEC.

6. PKI чрезмерно полагается на предположение, что подделать подпись нельзя, и должен быть передизайнен с дополнительными защитами.
Tags: computing, security
Subscribe

  • (no subject)

    Запоздалое, но большое спасибо всем, ответившим на предыдущий пост! Из предложеных версий мне кажется, что лучше всего "щёлкает" версия…

  • (no subject)

    Дорогие френды, а не просветите ли невежественного в русской истории кота? Отрывок из « Гимназистов» Гарина-Михайловского: Однажды, как только…

  • (no subject)

    Задумался вдруг над одной сценой из "Поттера" и внезапно она мне показалась очень нелепой. Не логически-технически нелепой (этих-то дыр не…

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 6 comments