Представлена централизованная база для проверки подлинности SSL-сертификатов

Представлена база для проверки подлинности SSL-сертификатов

Исследователи безопасности из университета Беркли объявили о создании некоммерческого сообщества ICSI Certificate Notary, которое будет поддерживать единую базу с информацией о валидности SSL-сертификатов.

Созданный сервис проверки сертификатов является попыткой решения ключевой архитектурной проблемы процесса сертификации - при компрометации одного из сотен центров сертификации, рушится вся цепочка доверия (злоумышленники могут сгенерировать сертификат длялюбого сайта, который будет воспринят всей системой как корректный). ICSI Certificate Notary позволяет выявлять такие обманные сертификаты на ранней стадии их появления, пишет opennet.ru.

На основе проведённой в течение года автоматизированной проверки, охватившей статистику по примерно 7.6 миллиардов SSL-соединений от 220 тысяч пользователей, собраны данные об около 500 тысячах сертификатов, используемых web-сайтами в сети. Данные накоплены с использованием нескольких независимых партнёрских систем, работающих в разных частях света. Информация обновляется в непрерывном цикле, что позволяет оперативно отследить факты компрометации сертификатов. Таким образом, используя ICSI Certificate Notary любой пользователь может убедиться, что сертификат, задействованный для создания SSL-соединения с заданным сайтом, выдан данному сайту, а не внедрён клиенту злоумышленниками для организации перехвата трафика.

Доступ к сервису организован в форме DNSBL. Проверка репутации сертификата осуществляется через отправку DNS-запроса в форме "хэш.notary.icsi.berkeley.edu", где хэш - SHA1-хэш от сертификата, валидность которого требуется проверить. В ответ будет возвращена TXT-запись с информацией о валидности сертификата, а также времени первой и последней проверки (например, "version=1 first_seen=15387 last_seen=15646 times_seen=260 validated=1"). Проверка сертификатов организована с задействованием поддерживаемого проектом Mozilla хранилища данных о корневых сертификатах. Интересно, что серверная часть организована с использованием оптимизированного для отдачи DNSBL зон DNS-сервера rbldnsd, созданного нашим соотечественником Михаилом Токаревым.

В HoneyCorn нашли способ устранить недостатки IoC

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

Методы атак развиваются быстрее, чем инструменты защиты. Ускоряется разработка эксплойтов, упрощается развёртывание атакующей инфраструктуры, сокращается время её жизни и растёт уровень маскировки.

Автоматизация, большие бюджеты киберпреступных группировок и использование нейросетей только усиливают этот тренд.

Один из ключевых инструментов защиты сегодня — индикаторы компрометации (IoC). Это машиночитаемые признаки атак: IP-адреса, хеши файлов, сигнатуры, домены, параметры фишинговых писем и другие технические артефакты. В идеале они должны быстро собираться при обнаружении новой атаки и распространяться по экосистеме, чтобы остальные компании могли заранее принять меры.

Чтобы противодействовать новым атакам сейчас, помимо прочего, используются индикаторы компрометации — это машиночитаемые паттерны, которые собираются при первой новой атаке и распространяются по всем пользователям. Это мощный, правильный и достаточно нерабочий инструмент на данный момент.

Давайте разберём почему.

  1. В классическом TI не собираются необходимые индикаторы компрометации в требуемом виде (базы паролей, используемых при брутфорсе, полные параметры фишинговых писем, семплы файлов, а также YARA-правила и хеши для инжектов и т. д.).
  2. Нет быстрой верификации индикаторов компрометации, в связи с этим — большое количество ложных срабатываний.
  3. Нет общепринятой классификации индикаторов компрометации по целевым спискам для решения всех необходимых задач и тюнинга количества ложных срабатываний.
  4. Нет единой унифицированной шины распространения индикаторов компрометации.
  5. Нет профессионального сообщества, обмена индикаторами компрометации для повышения базы сбора.
  6. Сейчас нет действенных механизмов сбора новых индикаторов без взлома реальных заказчиков.
  7. Не происходит автоматический реверс угроз нулевого дня.

И это только вершина айсберга – крутая технология становится посредственной из-за ряда практических недочётов.

В HoneyCorn заявляют, что нашли способы закрыть обозначенные пробелы. Детали проекта пока не раскрываются, однако команда приглашает к сотрудничеству других разработчиков ИБ-решений — для создания единой шины обмена индикаторами компрометации, а также компании-заказчики — для практического тестирования новых подходов.

RSS: Новости на портале Anti-Malware.ru