Атака BitErrant с коллизиями SHA-1: создаём разные .exe с одинаковым файлом .torrent

[SpyDeX]

Вот где правообладатели могут открыть новый фланг против пиратов.

[Sadler]

При этом правообладателям даже не нужно внедрять вредоносный код, достаточно генерировать случайные блоки данных с теми же хэшами и активно их раздавать, «инфицируя» всё больше сидов, в результате чего получить неповреждённый файл на выходе будет практически невозможно. Как правильно замечено, можно сверять полный хэш файла, но это, к сожалению, невозможно сделать, пока файл не скачан целиком, то есть либо придётся не раздавать во время скачивания, либо остаётся высокая вероятность распространения некорректных блоков.

[vanxant]

И даже в этом случае непонятно что делать. Ну убедились вы, что файл целиком не тот. Дальше что? Который из блоков сбойный неизвестно. Удалять всё к чертям и качать заново? У тех же самых пиров и сидеров? А смысл?

[Sadler]

В рамках неизменного протокола идеального решения нет. Вы можете строить статистику, выборочно блокировать сидов и т.п., но гарантировать корректный результат всё равно невозможно.

[wataru]

Понятно. Так же, как гит обходит эту проблему — поискать в файле один из двух известных блоков в коллизии. Заменить его на другой. Сейчас известно всего 2 блока, дающих коллизию.

[wataru]

Легко обходится перекодировкой видео, например. Не умеют генерить коллизию к произвольному блоку. Максимум, правоторговцы могут получить пару случайных блоков. Дальше их придется так же как в экзешнике, использовать в какой-то условной констиукции. Соотвественно, любое изменение файла перед раздачей ломает коллизию. Или эти странные условные конструкции можно легко вырезать.

[Sadler]

В случае видео/аудио никакие условные конструкции не сработают, вопрос лишь в том, как много коллизий можно сгенерировать на случайных блоках. Скажем, если у нас имеются десятки тысяч торрентов по 1000 блоков каждый (типичный такой фильмовой трекер), в скольких из них можно вытереть один блок? Два блока?

[wataru]

В средем 0 колизий. Не умеют генерить колизии к блоку. Более того пару блоков без датацентра никак не сделать. Там алгоритм сильно ускоряет перебор, но все равно дофига получается. Все пртмеры атаки сейчас используют те 2 единственно известных блока.

Сгенерить коллизию к любому из десятков миллионов блоков, возможно, в 10 миллионов раз проще, чем к одному. Все равно, этого никто делать не умеет.

[SagePtr]

С торрентами проще, достаточно добавить в начало раздачи какой-нибудь произвольный файл, не кратный размеру блока (например, текстовый файл с описанием). В итоге все потуги подменить блок пропадут зря, ибо файлы не выровнены по размеру блока. Поправьте, если ошибаюсь.

[IvUyr]

Самый главный вопрос: И как нам теперь с этим бороться?

[Sadler]

Использовать в протоколах более устойчивые хеш-функции.

[Alexeyslav]

Т.е. обратную совместимость — за борт?

[maxpsyhos]

Раз в 15 лет как-нибудь переживём.

[PKav]

Не надо ломать обратную совместимость. Просто реализовать поддержку обеих хэш-функций, но скачивать приоритетно с клиентов, поддерживающих более стойкую. Если ещё и раздавать приоритетно только новым клиентам, все быстро обновятся. Это же не IPv6, на который уже десятки лет перейти не могут.

[bormental]

Как уже предложили, использовать более сильный хеш.
Либо, в оригинальной статье есть ссылка на workaround: https://github.com/cr-marcstevens/sha1collisiondetection .

[polearnik]

использовать 2 хэш функции

[vanxant]

Вот поэтому сто лет уже как говорят про необходимость тройной подписи. Скажем, AES, ГОСТ и что-то дешёвое, но хорошо изученное — да хоть тот же CRC. Даже если во всех трёх есть бэкдоры, подобрать коллизию к такому тройному хэшу на много порядков сложнее.

[dmitryredkin]

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

[vanxant]

Формально всё верно, но речь вообще не о том.
Рассмотрим два случая:
1) У нас есть один хэш на 512 бит;
2) У нас есть два разных хэша, на разной математике, по 256 бит каждый.
Пока хэши не взломаны, стоимость перебора в первом случае 2^512, во втором — всего 2^257. Пока всё верно.
Но теперь допустим, что для первого хэша нашли закладку, снижающую стоимость перебора до 2^56 независимо от длины (такое бывало). В первом случае стойкость снизилась до 2^56 (дома не переберёшь, а вот в дата-центре можно), а во втором всего до 2^256. Почувствуйте разницу.

[tandzan]

Слишком замороченно. Ребята просто скачивают фриварный софт с официального сайта, оборачивают в свой враппер, чтоб заодно ставился условный «Амиго», и в таком виде выкладывают на трекер.

[wataru]

Опасность сильно преувеличена. Никто пока не умеет делать коллизию с произвольным блоком. Могут сделать 2 блока с одинаковым хешом. Т.е. оба экзешника сделаны вирусописателем.

Ситуация абсолютно аналогична сдедующей: есть вредоносный файл, который делает что-то полезное, но если вдруг решит, то расшифровывает вредоносную часть и исполняет ее.

Ничего нового. В худшем случае, будут бороться с пиратами и торентами, раздавая мусор. И то, это обходится обновлением протокола (давно пора) или перекодировкой медиа контента. Игры все равно приходится ломать, дак еще и проверку "сменного" блока придется отключать.

[Alcor]

оба экзешника сделаны вирусописателем

Не совсем так, к сожалению. Разработчикам ПО, насколько я понимаю, становится возможно синтезировать некоторый лаунчер и вредонос в пару к нему, продавать в комплекте с лаунчером, раздавать — с вредоносом.
В принципе, подобная атака давно используется правоторговцами, и не требует коллизий в sha1 (ситуация с неубиваемым шредером в черепашках-ниндзя ), но с ней становится легче.

[wataru]

А раньше что мешало так делать? Обратите внимание, в атаке меняется не часть кода а какие-то мусорные данные. Потому что, опять же, коллизии генерируются не к заданному блоку, а парой — два случайных набора байт с одинаковым хешом. Этот "безобидный" лаунчер должен всю вредоносную нагрузку нести с собой.

[Alcor]

Раньше для проведения такой атаки правообладатели должны были сами инициировать раздачу с заведомо вредоносным кодом. Теперь — достаточно нескольких пользователей с вредоносным лаунчером, причем им достаточно подключиться к уже существующей раздаче.

[wataru]

Как уже говорили в другой ветке, Эта коллизия используется только как триггер. Заведомо вредоносный код уже в лаунчере. Да, это триггер, который отлавливает пользователей торрента. Все-равно, легко обходится. А встроить его не в исполняемые файлы весьма сложно. А даже если он там есть, его можно чуть ли не руками отключить.

[amarao]

Выглядит как очень слабая форма атаки.

1. Вредоносный код уже раздаётся в торренте, а коллизия лишь позволяет быть триггером атаки.
2. При загрузке, в силу того, что пиры качают куски у кого попало очень трудно проводить таргетированную атаку.

В целом: для срабатывания вредоносного кода можно использовать куда более простые триггеры. Например, ip компьютера жертвы.

[Alcor]

1. Если вредоносный код не исполняется при обычном способе распространения, то не является проблемой.
2. Если файл меньше 16 КБ, то эта проблема исчезает.

[AlexGluck]

Добавить более стойкий хеш кусочков в торренты и добавить поддержку в клиенты. В случае если с sha1 по итогу загрузки есть проблема несовпадения хешей(проверка md5 итогового файла например), то проверять каждый кусочек с более стойким алгоритмом. Обратная совместимость сохраняется, так как есть и использование старых технологий и обход подмены кусочков в новой версии. По истечении некоторого времени поддержку говна мамонта из технологии выпилить и работать только с более стойким алгоритмом. Проблема потокового воспроизведения торрентов решается переключением на новый алгоритм, для потока всё равно нужен комп мощнее калькулятора.

[saboteur_kiev]

> Злоумышленник может создать исполняемый файл, который при исполнении не делает ничего запрещённого и выглядит безобидно, но меняет путь исполнения команд в зависимости от содержимого региона SHATTER.

Я представляю, что можно подобрать данные, которые выдадут такой же hash. Но насколько вообще реалистично написать НУЖНЫЙ ЗЛОУМЫШЛЕННИКУ код, и доделать блок таким образом, чтобы он не поломал работу в принципе, и выдал такой же hash?

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

[stetzen]

Нет, там предлагается нечто другое, насколько я понял. SHATTER — это не кусок исполняемого кода, это просто чанк с мусором. Зловредный код сидит где-то вне его в зашифрованном виде, но исполняется он только в том случае, если он сможет расшифроваться ключом, равным содержимому SHATTER. Судя по всему, опасность тут скорее социального плана — если сейчас торрент со зловредом (даже если его кусок кода зашифрован — в момент начала работы он очевидно будет задетекчен примерно всем, чем можно) на условном рутрекере достаточно быстро отправят в топку, то тут получается возможным создать формально чистый торрент, получить проверенный статус, который сводит на ноль уровень паранойи пользователей, после чего подменить его на такой, где зловредный код может включиться (тем более что к тому, что на кряки антивирусы реагируют, все привыкли и считают, что если кряк сначала был проверен администрацией, то всё ок). Кстати, это ещё раз говорит о потенциальном вреде, который наносят безопасности антивирусы тем, что реагируют на кряки без необходимости — тем самым они кричат «волки», подавляя бдительность и давая лишнюю возможность встроить в кряк реальный зловред.