23 февраля 2017 года сотрудники компании Google и Центра математики и информатики в Амстердаме представили первый алгоритм генерации коллизий для SHA-1. Эта находка стала результатом двухлетнего исследования, которая началась вскоре после публикации в 2013 году работы криптографа Марка Стивенса из Центра математики и информатики в Амстердаме о теоретическом подходе к созданию коллизии SHA-1. Он же в дальнейшем продолжил поиск практических методов взлома. Теперь вместе с коллегами из Google он опубликовал научную работу, в которой описаны общие принципы генерации документов с блоками сообщений, подверженных коллизиям SHA-1 (атака SHAttered).
Сразу стало понятно, насколько опасной может быть атака, ведь устаревшая криптографическая хеш-функция SHA-1 до сих пор широко используется, в том числе в приложениях и протоколах безопасности, включая TLS и SSL, PGP, SSH, S/MIME, IPsec. Хеши SHA-1 применяются в разных системах управления версиями Git, Mercurial и других для верификации содержимого и выявления повреждения данных (см. комментарий Торвальдса по поводу коллизий в Git). Хеши SHA-1 используются даже в игровой приставке Wii для проверки подписи во время загрузки. Использование SHA-1 по закону требуется некоторыми правительственными организациями. И самое интересное для темы данной статьи — хеши SHA-1 применяются в пиринговом сетевом протоколе BitTorrent для обмена файлами через Интернет.
Вкратце, как работает BitTorrent, а именно, как устроен торрент-файл.
Для раздачи файла через торренты на первом шаге нужно сгенерировать из этого файла (DATA) специальный торрент-файл с расширением .torrent (DATA.torrent). Оригинальный файл разбивается на определённое количество сегментов (chunks), для каждого из них вычисляется хеш SHA-1. Все полученные хеши соединяются вместе и хранятся в торрент-файле в строке
pieces под общим ключом словаря. Длина этой строки равна 20 * количество кусков.
Когда кто-то пытается скачать файл (DATA) через BitTorrent, сначала ему надо скачать торрент-файл DATA.torrent и распарсить его. Основываясь на информации из этого файла, клиент ищет пиров и скачивает сегменты оригинального файла (DATA). Чтобы защититься от пиров, которые пытаются подсунуть вредоносные данные, клиент сверяет каждый сегмент с его хешем из торрент-файла. Если хеш в торрент-файле не совпадает с хешем SHA1 в скачиваемом фрагменте, то плохой фрагмент отвергается.
Теперь вектор атаки становится понятен.
Злоумышленник может создать исполняемый файл, который при исполнении не делает ничего запрещённого и выглядит безобидно, но меняет путь исполнения команд в зависимости от содержимого региона SHATTER. При проверке антивирусами оригинальный файл не вызовет подозрений, потому что вредоносная часть хранится в зашифрованном блобе и никогда не запускается на исполнение.
И вот здесь начинается самое интересное.
Атака BitErrant
Если злоумышленник может создать два блоба данных с одинаковыми хешами SHA1, то при некоторых условиях можно сгенерировать два исполняемых файла с различными данными внутри. Но оба файла будут соответствовать одному и тому же торрент-файлу.
Если все условия соблюдены, то мы получаем два исполняемых файла, в которых одну часть можно заменить на другую. Если заменить её, то изменится путь исполнения команд и сработает вредоносный код.
Конкретно такую «переменную» функциональность исполняемого файла можно на практике реализовать благодаря протоколу BitTorrent. Принцип простой: мы начинаем сидирование через торренты «хорошим» файлом, а затем в определённый момент подменяем его «плохим», эффективно меняя фрагмент данных у тех, кто скачивает этот файл в сети пиров.
Демонстрация и инструментарий
biterrant_poc.zip
В архиве два исполняемых файла EXE с различной функциональностью (во вредоносном файле реализована начинка Meterpreter для фреймворка Metasplot, которая в данном случае начинает прослушивать все интерфейсы).
Пароль для расшифровки архива: biterrant.io
SHA1: eed49a31e0a605464b41df46fbca189dcc620fc5
Хороший файл на VirusTotal, плохой файл там же.
Автор атаки BitErrant разработал соответствующий инструментарий — фреймворк для генерации исполняемых файлов с одинаковыми .torrent. С помощью этого фреймворка можно помещать произвольную нагрузку в зашифрованную часть исполняемого файла и получить параметры для её вызова, которые затем помещаются в исполняемую часть файла. Потом на ваш выбор указываете невинные функции для подменяемой части хорошего файла. Затем питоновский скрипт генерирует два исполняемых файла — хороший и плохой — которые соответствуют одному файлу .torrent.
Пока что никто не применяет данную атаку для распространения файлов через официальные торрент-трекеры. Да и даже «хорошие» файлы с изменяемой функциональностью выглядят подозрительно для некоторых антивирусов. Так что опасность этой атаки не стоит воспринимать слишком серьёзно.
Чтобы защититься от этой атаки, достаточно всегда проверять общий хеш скачиваемого файла и сверять его с хешем файла, который стоит на раздаче, вот и всё. Между прочим, есть даже опция включать общий хеш MD5 файла прямо в торрент-файл, тогда данная атака станет неосуществима. В большинстве случаев никто эту опцию не использует.
Комментарии (30)
IvUyr
07.03.2017 12:35Самый главный вопрос: И как нам теперь с этим бороться?
Sadler
07.03.2017 12:37+2Использовать в протоколах более устойчивые хеш-функции.
Alexeyslav
07.03.2017 12:58Т.е. обратную совместимость — за борт?
PKav
07.03.2017 13:48+1Не надо ломать обратную совместимость. Просто реализовать поддержку обеих хэш-функций, но скачивать приоритетно с клиентов, поддерживающих более стойкую. Если ещё и раздавать приоритетно только новым клиентам, все быстро обновятся. Это же не IPv6, на который уже десятки лет перейти не могут.
bormental
07.03.2017 13:47Как уже предложили, использовать более сильный хеш.
Либо, в оригинальной статье есть ссылка на workaround: https://github.com/cr-marcstevens/sha1collisiondetection .
vanxant
07.03.2017 12:58Вот поэтому сто лет уже как говорят про необходимость тройной подписи. Скажем, AES, ГОСТ и что-то дешёвое, но хорошо изученное — да хоть тот же CRC. Даже если во всех трёх есть бэкдоры, подобрать коллизию к такому тройному хэшу на много порядков сложнее.
dmitryredkin
07.03.2017 13:27+1Для меня самого это плохо укладывается в голове, но умные люди возражают, что попытка дополнить более сильный (с криптографической точки зрения) хеш более слабым лишь незначительно (не на порядки) увеличивает перебор для создания коллизий.
vanxant
08.03.2017 00:13+2Формально всё верно, но речь вообще не о том.
Рассмотрим два случая:
1) У нас есть один хэш на 512 бит;
2) У нас есть два разных хэша, на разной математике, по 256 бит каждый.
Пока хэши не взломаны, стоимость перебора в первом случае 2^512, во втором — всего 2^257. Пока всё верно.
Но теперь допустим, что для первого хэша нашли закладку, снижающую стоимость перебора до 2^56 независимо от длины (такое бывало). В первом случае стойкость снизилась до 2^56 (дома не переберёшь, а вот в дата-центре можно), а во втором всего до 2^256. Почувствуйте разницу.
tandzan
07.03.2017 14:00+2Слишком замороченно. Ребята просто скачивают фриварный софт с официального сайта, оборачивают в свой враппер, чтоб заодно ставился условный «Амиго», и в таком виде выкладывают на трекер.
wataru
07.03.2017 14:16+1Опасность сильно преувеличена. Никто пока не умеет делать коллизию с произвольным блоком. Могут сделать 2 блока с одинаковым хешом. Т.е. оба экзешника сделаны вирусописателем.
Ситуация абсолютно аналогична сдедующей: есть вредоносный файл, который делает что-то полезное, но если вдруг решит, то расшифровывает вредоносную часть и исполняет ее.
Ничего нового. В худшем случае, будут бороться с пиратами и торентами, раздавая мусор. И то, это обходится обновлением протокола (давно пора) или перекодировкой медиа контента. Игры все равно приходится ломать, дак еще и проверку "сменного" блока придется отключать.
Alcor
07.03.2017 14:41оба экзешника сделаны вирусописателем
Не совсем так, к сожалению. Разработчикам ПО, насколько я понимаю, становится возможно синтезировать некоторый лаунчер и вредонос в пару к нему, продавать в комплекте с лаунчером, раздавать — с вредоносом.
В принципе, подобная атака давно используется правоторговцами, и не требует коллизий в sha1 (ситуация с неубиваемым шредером в черепашках-ниндзя ), но с ней становится легче.wataru
07.03.2017 15:07А раньше что мешало так делать? Обратите внимание, в атаке меняется не часть кода а какие-то мусорные данные. Потому что, опять же, коллизии генерируются не к заданному блоку, а парой — два случайных набора байт с одинаковым хешом. Этот "безобидный" лаунчер должен всю вредоносную нагрузку нести с собой.
Alcor
07.03.2017 15:38Раньше для проведения такой атаки правообладатели должны были сами инициировать раздачу с заведомо вредоносным кодом. Теперь — достаточно нескольких пользователей с вредоносным лаунчером, причем им достаточно подключиться к уже существующей раздаче.
wataru
07.03.2017 15:44Как уже говорили в другой ветке, Эта коллизия используется только как триггер. Заведомо вредоносный код уже в лаунчере. Да, это триггер, который отлавливает пользователей торрента. Все-равно, легко обходится. А встроить его не в исполняемые файлы весьма сложно. А даже если он там есть, его можно чуть ли не руками отключить.
amarao
07.03.2017 14:41Выглядит как очень слабая форма атаки.
1. Вредоносный код уже раздаётся в торренте, а коллизия лишь позволяет быть триггером атаки.
2. При загрузке, в силу того, что пиры качают куски у кого попало очень трудно проводить таргетированную атаку.
В целом: для срабатывания вредоносного кода можно использовать куда более простые триггеры. Например, ip компьютера жертвы.Alcor
07.03.2017 15:441. Если вредоносный код не исполняется при обычном способе распространения, то не является проблемой.
2. Если файл меньше 16 КБ, то эта проблема исчезает.
AlexGluck
07.03.2017 16:10Добавить более стойкий хеш кусочков в торренты и добавить поддержку в клиенты. В случае если с sha1 по итогу загрузки есть проблема несовпадения хешей(проверка md5 итогового файла например), то проверять каждый кусочек с более стойким алгоритмом. Обратная совместимость сохраняется, так как есть и использование старых технологий и обход подмены кусочков в новой версии. По истечении некоторого времени поддержку говна мамонта из технологии выпилить и работать только с более стойким алгоритмом. Проблема потокового воспроизведения торрентов решается переключением на новый алгоритм, для потока всё равно нужен комп мощнее калькулятора.
saboteur_kiev
07.03.2017 16:44> Злоумышленник может создать исполняемый файл, который при исполнении не делает ничего запрещённого и выглядит безобидно, но меняет путь исполнения команд в зависимости от содержимого региона SHATTER.
Я представляю, что можно подобрать данные, которые выдадут такой же hash. Но насколько вообще реалистично написать НУЖНЫЙ ЗЛОУМЫШЛЕННИКУ код, и доделать блок таким образом, чтобы он не поломал работу в принципе, и выдал такой же hash?
Думаю шанс подделки хеша нужно умножить на шанс возможности вышеупомянутого, и спокойно отдохнуть еще пару десятков лет.
stetzen
07.03.2017 20:48+2Нет, там предлагается нечто другое, насколько я понял. SHATTER — это не кусок исполняемого кода, это просто чанк с мусором. Зловредный код сидит где-то вне его в зашифрованном виде, но исполняется он только в том случае, если он сможет расшифроваться ключом, равным содержимому SHATTER. Судя по всему, опасность тут скорее социального плана — если сейчас торрент со зловредом (даже если его кусок кода зашифрован — в момент начала работы он очевидно будет задетекчен примерно всем, чем можно) на условном рутрекере достаточно быстро отправят в топку, то тут получается возможным создать формально чистый торрент, получить проверенный статус, который сводит на ноль уровень паранойи пользователей, после чего подменить его на такой, где зловредный код может включиться (тем более что к тому, что на кряки антивирусы реагируют, все привыкли и считают, что если кряк сначала был проверен администрацией, то всё ок). Кстати, это ещё раз говорит о потенциальном вреде, который наносят безопасности антивирусы тем, что реагируют на кряки без необходимости — тем самым они кричат «волки», подавляя бдительность и давая лишнюю возможность встроить в кряк реальный зловред.
SpyDeX
Вот где правообладатели могут открыть новый фланг против пиратов.
Sadler
При этом правообладателям даже не нужно внедрять вредоносный код, достаточно генерировать случайные блоки данных с теми же хэшами и активно их раздавать, «инфицируя» всё больше сидов, в результате чего получить неповреждённый файл на выходе будет практически невозможно. Как правильно замечено, можно сверять полный хэш файла, но это, к сожалению, невозможно сделать, пока файл не скачан целиком, то есть либо придётся не раздавать во время скачивания, либо остаётся высокая вероятность распространения некорректных блоков.
vanxant
И даже в этом случае непонятно что делать. Ну убедились вы, что файл целиком не тот. Дальше что? Который из блоков сбойный неизвестно. Удалять всё к чертям и качать заново? У тех же самых пиров и сидеров? А смысл?
Sadler
В рамках неизменного протокола идеального решения нет. Вы можете строить статистику, выборочно блокировать сидов и т.п., но гарантировать корректный результат всё равно невозможно.
wataru
Понятно. Так же, как гит обходит эту проблему — поискать в файле один из двух известных блоков в коллизии. Заменить его на другой. Сейчас известно всего 2 блока, дающих коллизию.
wataru
Легко обходится перекодировкой видео, например. Не умеют генерить коллизию к произвольному блоку. Максимум, правоторговцы могут получить пару случайных блоков. Дальше их придется так же как в экзешнике, использовать в какой-то условной констиукции. Соотвественно, любое изменение файла перед раздачей ломает коллизию. Или эти странные условные конструкции можно легко вырезать.
Sadler
В случае видео/аудио никакие условные конструкции не сработают, вопрос лишь в том, как много коллизий можно сгенерировать на случайных блоках. Скажем, если у нас имеются десятки тысяч торрентов по 1000 блоков каждый (типичный такой фильмовой трекер), в скольких из них можно вытереть один блок? Два блока?
wataru
В средем 0 колизий. Не умеют генерить колизии к блоку. Более того пару блоков без датацентра никак не сделать. Там алгоритм сильно ускоряет перебор, но все равно дофига получается. Все пртмеры атаки сейчас используют те 2 единственно известных блока.
Сгенерить коллизию к любому из десятков миллионов блоков, возможно, в 10 миллионов раз проще, чем к одному. Все равно, этого никто делать не умеет.
SagePtr
С торрентами проще, достаточно добавить в начало раздачи какой-нибудь произвольный файл, не кратный размеру блока (например, текстовый файл с описанием). В итоге все потуги подменить блок пропадут зря, ибо файлы не выровнены по размеру блока. Поправьте, если ошибаюсь.