С 20 марта 2017 года при вычислении хешей SHA-1 на GitHub определяется и отклоняется любой контент, который обладает признаками возможной атаки SHAttered на коллизию хешей SHA-1. Об этом компания написала в официальном блоге. Таким образом, никто не сможет размещать здесь файлы из пары с одинаковыми хешами, но разным контентом. Хотя пока на практике таких атак никто не проводил нигде, кроме торрентов, но GitHub решил перестраховаться на всякий случай.
Почти месяц назад сотрудники компании Google и Центра математики и информатики в Амстердаме представили первый способ генерации коллизий для хеш-функции SHA-1. Атака SHAttered стала результатом двухлетнего исследования, которая началась вскоре после публикации в 2013 году работы криптографа Марка Стивенса из Центра математики и информатики в Амстердаме о теоретическом подходе к созданию коллизии SHA-1. Он же в дальнейшем продолжил поиск практических методов взлома вместе с коллегами из Google. Опубликована научная работа, где описываются общие принципы генерации документов с блоками сообщений, которые подвержены коллизии SHA-1.
Вскоре после публикации документа появился и первый образец её реального использования в приложениях: атака BitErrant, позволяющая создать два одинаковых торрента (файл .torrent) с одинаковыми хешами, но которые соответствуют разным файлам. Один — обычный исполняемый файл, а другой — вредоносный файл с начинкой Meterpreter для фреймворка Metasploit.
Линус Торвальдс заявил, что коллизий SHA-1 в репозиториях Git бояться нечего. Он объяснил, что есть большая разница между использованием криптографического хеша для цифровых подписей в системах шифрования и для генерации «идентификации контента» в системе вроде Git. В первом случае хеш — это некое заявление доверия. Хеш выступает как источник доверия, который фундаментально защищает вас от людей, которых вы не можете проверить иными способами. Напротив, в проектах вроде Git хеш не используется для «доверия». Здесь доверие распространяется на людей, а не на хеши, говорит Линус. В проектах вроде Git хеши SHA-1 используются совершенно для другой, технической цели — просто чтобы избежать случайных конфликтов и как действительно хороший способ обнаружения ошибок.
Несмотря на мнение Торвальдса, разработчики GitHub решили, что перестраховка никогда не помешает, так что теперь эта платформа защищена от размещения файлов и кода из пары с одинаковыми хешами.
В отличие от Торвальдса, разработчики GitHub считают, что корректная работа SHA-1 действительно важна для Git. Они не спорят с самой логикой его рассуждений, просто указывают на то, что проведение такой атаки действительно возможно на практике в Git. Они даже описывают примерно, как такая атака может выглядеть. Нужно учитывать, что атака невозможна на ранее созданные объекты. Для её проведения злоумышленнику нужно специально создать одновременно создать два новых объекта с одинаковыми хешами. Они будут во всём одинаковыми, кроме маленькой секции отличающихся данных.
В это случае атака может быть проведена по следующему сценарию:
- Сгенерировать пару объектов, где один выглядит нормально, а другой делает что-то вредоносное. Это лучше всего делать с бинарными файлами, где люди на глаз вряд ли заметят разницу.
- Убедить мейнтейнеров проекта принять «невинную» половину пары и дождаться, когда они присвоят тег или сделают коммит с этим объектом.
- Распространить копию репозитория, в котором невинный объект заменён на вредоносный (например, разместив где-то на стороннем сервере и предъявляя всем доказательства аутентичности копии по идентичному хешу). Каждый после проверки подписи будет думать, что содержимое этого проекта соответствует содержимому оригинального репозитория.
Атака SHAttered всегда оставляет следы — некую специфичную последовательность байтов, одинаковую в обеих частях пары. Её можно обнаружить, если вычислить SHA-1 для любой части пары. GitHub теперь проводит такую проверку при каждом вычислении хеша.
Код для определения специфической последовательности байтов написан Марком Стивенсом и Дэном Шамовым и опубликован в открытом доступе.
Пока на GitHub не было ни одной коллизии хешей, по её словам. PDF-файлы из оригинального примера атаки дают одинаковые хеши сами по себе, но не в репозитории Git, потому что здесь при расчёте хеша учитывается ещё некоторая техническая информация Git.
Есть некоторая вероятность, что алгоритм автоматической блокировки сработает на любом коде или файле, который размещён вовсе не с целью последующей подмены и атаки. Но тут уж ничего не поделаешь. Придётся изменить свой код, чтобы снять блокировку.
Разработчики GitHub даже подсчитали, какова вероятность случайно написать такой код, который будет подвержен блокировке. Если пять миллионов программистов будут генерировать по одному коммиту в секунду каждый, то шанс случайной коллизии к моменту превращения Солнца в красный гигант составляет около 50%.
Разработчики GitHub сейчас работают совместно с Git, чтобы включить библиотеку для распознавания коллизий в общий проект. Кроме того, в Git сейчас разрабатывают план по переходу с SHA-1 на более безопасную хеш-функцию с минимальным ущербом для существующих репозиториев.
Автор: alizar
